Re: [Gnu-arch-users] s/GMT/UTC/

[Jeremy Shaw]

> UTC inserts leap seconds, so the date counter can't be easily converted
> to seconds. GMT on the other hand stretches the seconds, so the interval
> corresponding to some number of seconds is not defined.
> 
> The article at:
> http://www.ucolick.org/~sla/leapsecs/onlinebib.html
> contains some discussion of how POSIX time and NTP time should be viewed
> and concludes, that it's appropriate to consider them UT, that is GMT,
> rather than UTC.
> 

This article gives a slightly different insight into ntp and leap
seconds and UTC:

http://www.eecis.udel.edu/~mills/leap.html

It indicates that under Linux(??) you can use ntp and precision time
kernel modifications to keep your clock synced with UTC, even during
leap seconds.

Which indicates to me, that the UTC vs GMT vs UT1 vs etc, really
depends on how you sync your system clock, and whether you attempt to
convert from your system time to a different time. With enough time
and money, I certainly could sync my clock to GMST (greenwich mean
solar time, a term used to indicate that you really mean the solar
time).

But in reality, perhaps I am lazy and don't sync my clock to anything!
This tends to make the timestamps in tla pretty useless. If you
attempt to write a program that correlate the time stamps, you are
just going to screw yourself over, unless you have some out of band
data that gives you reason to believe the timestamps are
meaningful. Even within a single archive, if I commit from several
different machines that are not time synchronized, the patch log
timestamps will be "useless".

And, what event is the timestamp supposed to corrolate to anyway? If I
write a tla clone, how to I make my timestamps 'mean the same
thing'...

It would actually be useful to have meaningful time stamps in tla. For
example, we (linspire, inc), have an debian package autobuilder. It
can not only build single packages, but also track build dependencies,
and build a whole build dependency graph. 

If tla timestamps could be trusted, then I could say, build the
package family for package X based on the state of the world right
$NOW. This is useful, because even if other commits happen after $NOW,
they will not affect the build. Or, I could even say, build the
package based on the state of the world on 'Sept 1, 2004 2:23:45UTC'.

But, I can't do this now, because I there are no trust worthy
timestamps in patch logs.

Of course, it should also be clear by now, that if I want this
property, I need to have a comprehensive time policy that encompases a
whole bunch of things outside the scope of tla. So, I really just need
a hook that will let me specify my own timestamp. X-Linspire-Time:
yada yada yada.

I might even be able to do this already with a pre-commit hook --
haven't looked yet. It's a nice feature, but not an essential feature.

Some people feel that the current time stamps are nearly worthless and
should be removed altogether. I think this is a bit extreme, but it
would prevent someone from mistakenly believing the timestamps can be
trusted to any degree. (And it would 'fix' one of the rfc2822
incompatabilities).

Jeremy Shaw.

ps. As a side note, does any know if/how bitkeeper synchronizes
timestamps in a distributed system?
--

This message contains information which may be confidential and privileged. 
Unless you are the 
addressee (or authorized to receive for the addressee), you may not use, copy 
or disclose to anyone 
the message or any information contained in the message. If you have received 
the message in error, 
please advise the sender and delete the message.  Thank you.