Re: CVS timestamps

[Larry Jones]

Matthew Berney writes:
> 
> I find it hard to believe that a tool that works across multiple timezones
> does not support a way to localize the timestamps?  Why not use the TZ
> environment variable?  This is pretty standard isn't it?  It would be nice
> to have the timestamps in the repository actually match our local time.

Localizing the timestamps in the user interface would be eminently
reasonable.  In fact, CVS already does that for input: any place you can
input a timestamp to CVS, it's assumed to be in local time unless you
specify otherwise.  Unfortunately, doing the same for output would
require a complete overhaul of the client/server protocol since it is
currently the server that converts timestamps into human-readable
strings but only the client knows the rules for converting UTC into
local time.  It might actually be possible to do without changing the
protocol by making use of tagged text, but it would still require a lot
of code changes.  If anyone is looking for a worthwhile and challenging
project, I'd say this would be a good one.

On the other hand, localizing the timestamps in the repository doesn't
make any sense.  Most civil times are not suitable for use as
timestamps; many jurisdictions have some form of daylight saving or
summer time which typically results in a one hour gap of non-existant
times in the spring and a similar period of duplicated times in the
fall.  The only way to deal with this would be to store the prevailing
time standard along with the local time, in which case you might as well
just store UTC and be done with it.  Not to mention the problem of
determining exactly which local time is *the* local time to be stored:
The server's?  The client's?  *Which* client?

-Larry Jones

This sounds suspiciously like one of Dad's plots to build my character.
-- Calvin