>From: Nuutti Kotivuori <email@example.com>
>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
> From: Nuutti Kotivuori <firstname.lastname@example.org>
> 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.
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
> Or something completely different?
I'd rather see ISO-8601 style format used as much as possible.
> 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.
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.
> 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...
> 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
> Again, opinions and suggestions, please :)
> -- Naked
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sun May 19 17:40:18 2002