On 23/12/11 11:19, Jay Daley wrote: [stuff about aligning UTC with TAI] One thing folks should be aware of is that the "UTC" on your computer is not UTC at all. Oh, the /current/ time might be correct, but the way leap seconds are implemented is simply to adjust the clock by a second, not to adjust the representation of the time. Thus, you find that the time stored in your computer is the number of seconds since midnight, 1 January 1970, as if there were no leap seconds inserted. Zero time on Unix and Unix-derived systems is actually 1 Jan 1970 00:00:24 UTC. The Unix time APIs allow for leap seconds, e.g. this extract from a Linux /asctime()/ man page: _tm_sec_ The number of seconds after the minute, normally in the range 0 to 59, but can be up to 60 to allow for leap seconds. but this element of the API has never been implemented. Introducing leap seconds to Unix time in a way that would make this API element correct would actually break stuff, because, for example, time modulo 60 gives seconds past the minute boundary, and introducing leap seconds into the system time would break anything that assumed this was true. It would also create problems when time from a system implementing leap seconds is presented to one that that isn't. The reality is that insertion of a positive leap second involves back-stepping, stopping or slewing the clock. That means for the duration of the adjustment, at least one "second" is not actually a second long. It's a small thing for most protocols (most of us have learned to live with time discontinuities, as they happen due to loss and/or subsequent regain of time synchronisation a lot more often than due to leap seconds ... has anybody else fixed ntpd, and suddenly had their screen-saver kick in?), but the fact remains that leap second are handled in a way that can only be described as introducing an error. On average, a leap second is added every two years -- it varies, there have only been two since 2000, vs one or even two a year through the '70s. At a rate of one every two years, it'll be over three thousand years before the time offset from celestial time reaches half an hour, at which point folks might start to notice. That's rather longer any widely used modern calendar has been codified to any level of accuracy.. My personal view: Stop doing leap seconds for time co-ordination. Publish tables of UTC to celestial time offsets, with suitable libraries and APIs. Make it more accurate than applying leap seconds, so it' s really useful to those who actually care about astronomical position, and can be safely ignored by those who don't. Stop messing with the actual ticker, and live with the 34 second offset to TAI. Just to put this into perspective, at about a quarter past three* in the morning of Tuesday, 19 Jan 2038, 32 bit signed Unix time will roll over. That's in just over 26 years. New industry hires will have to deal with this during their careers. And it's not just a matter of "upgrading" to 64 bit time; you have top deal with 32 bit fields in file systems and various other data storage formats. It'll be Y2K all over again, except harder to explain to the masses. -- don * The exact time of this event depends on what happens with leap seconds.