Mark D. Baushke wrote:
>>From: Nuutti Kotivuori <naked@iki.fi>
>>Date: Sun, 19 May 2002 16:58:57 +0300
>>
>> And the third choice is to do what I mentioned in the very
>> beginning - make a revision that understand the new timestamps, but
>> produces old timestamps still. And then postpone the timestamp
>> changing until a new bootstrap tarball is released naturally. This
>> would be quite a catch all solution - it would enable us to
>> incrementally fix everything everywhere and just do the jump
>> whenever it's suitable. But ofcourse it's a bit elaborate for such
>> a small change.
>
> This suggestion seems to be the only way to make a smooth
> transition...
Yes, this is what I am proceeding with - expect results in not so
long.
>> From: Nuutti Kotivuori <naked@iki.fi>
>> Date: Sun, 19 May 2002 17:22:09 +0300
>>
>> First there is the issue of the actual format - is ISO-8601
>> human-friendly enough, or do we want to print a space instead of
>> 'T' as the delimiter.
>
> I have seen a space used instead of a 'T' in other applications when
> the output was not intended to be machine parsed later. This seems
> to be a nominal variation that makes it easier to read for most
> humans.
Yes, it is common.
> I'd suggest that any internal string form reatain the T and stay in
> UTC and optionally replace it the T with the more friendly space
> based on a user/site configuration option for display and the Z
> based on the local timezeone.
The "internal" string form is now completely separated from the user
display. The humanized date display always comes directly from
apr_time_t to a string - and is never parsed back.
>> Or something completely different?
>
> I'd rather see ISO-8601 style format used as much as possible.
Me too.
>> Then what about timezones - should the outputted dates be UTC
>> always - or should they be printed in a local timezone? I
>> personally would wish for something as close to ISO-8601 as
>> possible, but your mileage might vary.
>
> The ISO-8601 format allows for both local time (the Z is dropped)
> and specification of an offset from UTC.
>
> 2002-05-19T17:22:09+03:00
> vs 2002-05-19T14:22:09Z
>
> If you use '2002-05-19T17:22:09' it means 'local time' but does not
> specify the timezone. I would rather not see this form used other
> than as allowed input from the user.
Yes, dropping the timezone altogether is bad. And the ISO-8601 format
for dates with timezones is fine by me - just that I do not know if
others agree that it is a good one. In any case, I think we should
avoid timezone _names_ like 'GMT', 'EST' and so on - unless ofcourse
those things come directly from locale.
>> Then there is the issue of customization - do we want the user to
>> be able to specify the format timestamps show in?
>
> I'd suggest that being able to configure the local timezone may be
> reasonable, but I think it might be easier to just use ISO-8601
> variations than allowing for a strftime format string approach.
>> If yes, how does the user specify the format?
>
> Probably via something like an strftime() format string. Note that
> the ISO-8601 specification for the first day of the week (Monday) is
> different than the strftime() form which uses Sunday...
We would be using the strftime provided by APR - and that is quite
fine by me. But a mere strftime is not enough - we need an additional
option for the local timezone or UTC selection.
>> And here the biggest issue for me is that I have no idea how the
>> configuration file should be used in svn. Or should this thing be
>> done in a separate phase again - first a simple user display
>> format, then a customizable one past-1.0 or something?
>
> Putting it off may be easiest. For now, it might be enough to pay
> attention to the TZ environment variable to use the local timezone
> offset with the possibility of extended format configuration
> capabilities later.
Well, I can make an intermediate solution that just uses strftime with
a decent default format string.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 19 17:55:07 2002