I'd like to tackle this issue on ASAP - though I might get busy from
work in the near future. But this manages to really annoy me in svn
right now :)
OK, first let's see if I understand the related matters correctly.
The pressure onto moving to ISO-8601 comes from two issues:
First, the WebDAV creationdate - RFC2518 specifies that
creationdate must be an ISO-8601 date - and not only any ISO-8601
date, but a very specific format. So, to comply with the RFC, we
must change the date format that travels over the wire.
Second, user representation - it would be nice if the date
presented to users would be a standard date instead of something
that is only near it. This second point is what got me interested
about the issue - I want the dates to be ISO-8601.
If I understand the current situation correctly, all time to string
conversion happens with two functions: svn_time_from_nts,
svn_time_to_nts - and these make an exact representation of the
apr_time_exp_t structure - even if the structure contains very weird
information. But the result is long and not too well suited for human
representation in it's entirety.
But you are saying that there's actually no need for these functions
to behave that way for subversion, it's just nice that they exist and
behave that way - and hence should not be scrapped? Well quite
reasonable I guess.
So, what needs to be done. I guess we need the functions to handle
both of the issues mentioned - on the wire and user presentation. On
the wire format needs to be able to translate the timestamp both ways
- to string and from string. And hopefully it would atleast be
non-lossy with apr_time_t, even if not containing all the cases
apr_time_exp_t can represent. The user representation needs only
conversion to string - and the representation can be lossy. Actually,
it might even be possible to have configurable timestamp formats - but
we'll come to that later.
OK, the format specified by RFC2518, which would be used on the wire,
when containing all items and assuming we wish the timestamps
travelling over the wire to be UTC, would be either one of these:
2002-05-04T12:34:56.999999Z
2002-05-04T12:34:56.999999-00:00
The difference is mentioned as:
,----
| If the time in UTC is known, but the offset to local time is
| unknown, this can be represented with an offset of "-00:00". This
| differs from an offset of "Z" which implies that UTC is the
| preferred reference point for the specified time.
`----
I'm unsure which one I would prefer - but I would possibly go for the
"Z". Although we do not know the offset to the local time, the UTC is
the preferred reference point for all times going over the wire. But I
don't really know.
For the user represented format, there's a bit more issues. Right now
there's that something humanize date which was used in svn log - and
hand cooked printfs in svn info. Both of those should probably be
scrapped.
But what do we really want to do? Do we want to print timestamps in
UTC? Or do we perhaps want to honor the users timezone and print them
accordingly? Or would we even want to specify a configuration option
for time stamp format that the user would see in svn log and svn info
atleast?
Then another issue - it would appear from the comments on the issue,
that there is yet another place where ISO-8601 times would be wanted -
repository. Or actually everywhere where dates go to string form and
back. Well this is a bit of a bigger issue I guess :)
Are svn:date properties the only place where dates are in string form
in the repository? Would we want to convert dates somewhere, or just
remain backward compatible? We do want to remain backward compatible
without special mangling to the repository do we? What about the over
the wire format - do we need to be backwards compatible with clients
that send old style dates? Do we need to convert them before putting
them into the repository? What about sending dates to old clients? I
hope we don't have to convert dates to old format for old clients?
Oof, this was a bit uncoherent - but that's because I'm in a rush.
Help me on this, tell me what to do - this might not be a small
matter, but I personally think it should go in before alpha or
whatnot. And I'm willing to put in effort to make it happen.
TIA,
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 4 19:09:01 2002