Re: Dates: the can of worms

On Sat, 1 May 2004 22:47, Iljitsch van Beijnum wrote:
> That remains to be seen... I agree _today_ it doesn't matter much, but
> we're moving into a direction of more and more accurate time keeping. I
> can imagine a situation where the emission of packets to the network is
> done at very exact times to allow for better quality of service. A 0.9
> second time difference in various places would be deadly here.

This is why you would use MJD-timestamps for relatively low resolution tasks 
(where error margins of a minute don't matter). The "Date" header in an email 
is a good example: its primary purpose is to indicate the day and time-of-day 
that a message was created. Any nitpicking at the second level really misses 
the point.

For network synchronisation, the timestamp doesn't need to be converted into a 
calendar-based format at all, and a raw number of atomic seconds can be used. 
Following the format of the MJD proposal, you could have a TAI epoch and 
units of atomic seconds, like "TAI+123456.789". Dan Bernstein has already 
proposed a conceptually similar thing called "taiclock" (which is primarily 
targeted as a replacement for NTP).

These things can be quite independent of each other, and used for distinct 
purposes. If desirable, you can have a function which converts (or 
approximates) one time from another.

The general epoch-offset format makes timestamps trivial to generate, trivial 
to parse, trivial to compare magnitude (sort), and trivial to use in 
time-interval computations (with results in the same unit as the format). 
Using units of solar days (as for my MJD proposal) makes dates immune to 
calendar changes, up to and including the introduction of Metric Time and the 
Ten Day Week. Using units of atomic seconds (as for the TAI suggestion) 
optimises the format for real time sub-second accuracy, not conversion to 
civilian dates.

> This sounds like the way we simple humans like to use time.
> Unfortunately, I never see "UT1" anywhere, just "UTC" and:

Yeah, but every wall clock and wrist watch you ever see works on the basis of 
86400 seconds per day. That's not UTC. Given two extremely accurate clocks 
running UT1 and UTC respectively, you'd note that there was less than a 
second's difference between them, and you'd only be able to figure out which 
one was the UTC clock if you saw a leap second like 23:59:60.

Dates are a can of worms. You can go nuts arguing about them. But think of how 
often people hard-code an assumption like "there are exactly 60 seconds in a 
minute". Note that it's not a true assumption in UTC calculus.

> > A date can be expressed in the form "MJD+53125.1666",
> > and this would have meaning to historians who already 
> > use MJD.
>
> How many bits does it use?

As a variable length string representation, the example I gave was 14 bytes, 
but the length is generally variable, depending on how precise you want to 
be. If you parse it into a standard double precision floating point number, 
you'll use 8 bytes of memory (64 bits) and have at least one-second precision 
for epoch plus or minus about a billion years.