kre at munnari.OZ.AU
Thu Jun 30 00:22:12 UTC 2011
Date: Wed, 29 Jun 2011 14:27:53 -0400
From: Paul Koning <paul_koning at Dell.com>
Message-ID: <1ED832E5-A4DA-4BCC-8273-BA2715F12017 at dell.com>
| I wonder if this requests amounts to "Posix should be extended to
| provide an interface to TAI". If so, that certainly makes sense.
| Is that something tzdata can do, or does it have to be done in some
| other layer?
It is a mess. Do remember that POSIX time is really neither UTC nor TAI.
That is, it acts like TAI, but the value is the same as it would be if it
were UTC. POSIX manages this by making seconds be variable length objects,
so there's always exactly 31536000 of them in a year (31622400 in leap years).
That is, given that the time was (a minute and a bit ago as I type this)
1309392000 seconds past the unix epoch (Jan 1, 1970 00:00:00), we can
calculate the date by simple arithmetic,
1309392000/31536000 == 41 (rounded down)
so 41 years have passed, which means 10 leap years (and yes, I know that
in reality this would take more work to evaluate, but happens to be right in
this case just doing 41/4), so 10 extra days to allow for, or 864000 extra
41 * 31536000 + 864000 == 1293840000
So, we must be 1309392000 - 1293840000 seconds into 1970+41 (2011).
That is, 15552000 seconds into 2011. 15552000/86400 == 180, so 180
days have passed (and 180*86400 == 15552000 so exactly 180 days had
passed - and yes, by co-incidence, it was exactly UTC midnight when
I looked at the time value - or close enough that I just subtracted away
the extra 100 or so seconds for the purposes of this e-mail).
180-31-28-31-30-31 == 29 That's Jan Feb (non-leap) Mar Apr May, so 29
days have passed in June, so it must be (have been 10 mins ago now)
midnight on June 30, 2011, UTC. And yes, that's what it was.
Now notice the notable lack of any reference to any table of leap seconds
in the calculations above. So, we have something that looks like TAI.
Except the TAI time would be 14 (?) seconds different than this, so it
isn't TAI either - instead we have the wonderful POSIX seconds.
In order to make this work, every time there's a leap second added, POSIX
seconds all have to get a little larger, and if there was ever a leap
second removed, POSIX seconds would all have to get a little smaller...
This is a bizarre definition of time from any physics, or astronomy sense,
but happens to be almost ideal for everything else (regular time measuring)..
It just fits most people's expectations of how time works, where esoteric
stuff like leap seconds can be just ignored.
ps: the only problem with adding a TAI zone, is that it requires a leap
second table that's constantly updated - the nice thing about POSIX time
is that (summer time complications aside) no external data is required to
convert a unix time_t into a human clock value, and vice versa, so as
long as the summer time rules don't change (or don't exist) - which actually
covers most of the world, most of the time, nothing ever needs to be
More information about the tz