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.