[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dates: the can of worms


On 1-mei-04, at 6:28, Brett Watson wrote:

An interesting question is whether it's better to implement a binary
date format as a timestamp or a concatnation of
year/month/day/hour/second fields.

I can see that you've thought about this, but it seems you still haven't quite
noticed how full of worms the "dates" can is.

I think it's mostly one worm: the rotation of the earth around its axis and the orbit of the earth "around" the sun (*) aren't fixed length periods.

The last time I studied up on dates, I was prompted to write a short essay about it, which you may find amusing (and even informative).

http://www.nutters.org/log/dating-game

:-) How did you become famous, anyway?

(BTW I once implemented a date format as a floating point value
counting the days since Y2K, which gives good precision right now but
still allows dates far in the past and future. And ignoring the leap
second problem is easier.)

That's actually not a bad approach, and ignoring the leap seconds problem
isn't as evil as some might think.

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.

We actually have (at least) two
"universal" times: UTC and UT1. UT1 is a purely solar time, and always has
86400 "seconds" per day. The fundamental unit of UT1 is the "day", where
"day" is a rotation of the Earth relative to the sun, and all the smaller
components are constant fractions of that day.

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

In UTC, the fundamental unit is the "atomic second" (which is what the SI
nomenclature considers a "second" to be). Given the current rules of UTC, a
"day" is 86400 seconds, with an optional one-second adjustment (plus or
minus) on leap second days,

There's also TAI, which is UTC without the leap seconds. That is, it is based
around the atomic second with exactly 86400 atomic seconds per day, but it
drifts with respect to the solar day because it lacks leap seconds.

This is the one we must avoid.

Given the purpose and nature of date-stamps in email, I would advocate using
UT1 as the time base. UTC is a PITA because of arbitrary leap seconds, and we
don't have any use for the precision of atomic seconds in this application.
TAI isn't useful for civilian timekeeping. In UT1 there are always 86400
seconds in a day (simple! predictable!), and it provides a date-stamp which
is with 0.9s of UTC, which strikes me as more than good enough for the job.

It's not that easy. I think in the future systems will want to provide more accurate time, at which point stretching seconds to make sure 86400 fit in a day is no longer acceptable, so UT1 is out. TAI is also unacceptable, because of cognitive dissonance (read: support cost) problems. So if and when accurate time becomes important for regular computers, I think they'll adopt "real" UTC. This of course makes for lots of interesting problems. We can at least make sure that mailng doesn't add to these problems by adopting a date format that supports both UT1 and UTC, even when a system isn't explicitly aware of which it's using. In other words: we need to guard the integrity of the day transitions so that we don't end up with a cumulative and unpredictable error factor such as with TAI.

(Please note that the "second" component of an RFC2822 time-of-day production
is already optional.)

Hmmm... If we throw out the second we get rid of the leap second as well and it gives us 8 millennia to work with in 32 bits rather than 134 years with a second-based timestamp. (68 years in practice because we can't be sure that a stupid programmer hasn't defined the timestamp as signed in one place or another.)

Rather than use the number of days since the year 2000, however, I suggest
using the Modified Julian Day, simply because it's a standard epoch that
someone else already invented. 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?

(*) The notion that planets simply revolve around the sun in a fixed orbit is a gross oversimplification of what Newton had to say about the subject, let alone Einstein. For instance, ignoring all other factors, the moon doesn't so much revolve round the earth as that they both revolve around a shared center of gravity, which happens to be located around 1500 km below the earth's surface.