RE: CVS timestamps

[Matthew Berney]

Agreed.  The server should save whatever time is necessary.  UTC seems
reasonable as it is global.  For open source repositories, this makes sense.
>From a user's perspective, I don't care if it is done on the server or the
client.  When I look at the revision history, (i.e. cvs logs, cvs history,
cvs status, etc.), it would be nice to relate this to "my" time.

A perfect example of this...I have a perl script which uses cvs history and
cvs annotate to keep track of the rate of change in our repository.  This
tool is always 8 hours off.  So, anyone who checks in their code after
2:00PM, the recorded change for cvs history purposes is the next day.

Matt

-----Original Message-----
From: address@hidden [mailto:address@hidden
Sent: Thursday, October 05, 2000 1:41 PM
To: address@hidden
Cc: address@hidden
Subject: Re: CVS timestamps


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