[time-nuts] Leap Quirks

[Chuck Harris]

Magnus Danielson wrote:
> Chuck Harris skrev:
>> One of us is confused about what time_t is... I think it is
>> you.
> 
> I know of three different ways to interpret it. They fit different purposes.
> 
>> time_t is a 32 bit (depreciated), or 64 bit integer that contains
>> the number of seconds since the epoch.  It is not to be adjusted
>> for leap seconds according to POSIX, and unix convention.
> 
> This is one, no two, of the interpretations I know of.

Good!

>> Everything to do with UTC and leap seconds is a library function
>> in most unixes that translates the leap second free time_t into
>> the leap second adjusted broken-down-time UTC.
> 
> Exactly where? Do please tell me what the unified way of getting UTC 
> time is. Oh, when there is a leap second it needs to give correct 
> counting as well.

If the unix supports leap second, which usually requires ntp, gmtime()
should report the UTC time correctly.

> Joe has in private conversations pointed out a POSIX interface which 
> could be used.
> 
>> Again, are you telling me that time_t is getting adjusted for leap
>> seconds?  If so, when did this change?
> 
> To the best of _my_ knowledge (which can be wrong) this is what is being 
> done in practice, which is outside of the POSIX standard, but has the 
> effect that 00:00:00 always midnight, which POSIX needs. This is a third 
> interpretation...

Yes, but this is not UTC midnight, but unix time or POSIX time midnight.
Unix time midnight, and POSIX time midnight drift from UTC midnight as the
leap seconds get added or removed.

Some of the libc functions that convert time_t to broken down time convert
to UTC, and others convert to POSIX/Unix time... which is, I guess 24 seconds
fast?

Ntpd doesn't mess with time_t when it makes its leap second corrections,
but rather messes with tables and counters used by gmtime(), etal..  The
only time that ntpd messes with time_t is to slew it so that your system's
time_t is the same as everyone elses... (The number of si seconds since
the epoch without adjustments for leap seconds.)


> If somebody (say PHK) got out and slapped my face and say this is a 
> total misunderstanding, this is pretty good after all. If this practice 
> does exist, then we still have three interpretations and they are in 
> conflict with each other even after giving up on introducing leap 
> seconds. So we have two or three interpretation of the POSIX timescale, 
> one with pure SI seconds, one with rubber seconds up till 
> 1972-00-00T00:00:00Z and then SI seconds and a third which is like the 
> second but re-aligned on each leap second event so that midnights match.
> 
> This is only an issue if the POSIX scale is under external control.
> 
> And yes, do tell me how I get UTC on all platforms.

On all platforms?  Even my VCR?  That's a tall order.  On unix
platforms, gmtime() will do the trick... assuming that leap seconds are
supported.

> 
> Regardless, this just shows how complex the issue is. There seems that 
> there is no "correct" interpretation that everyone can agree with as a 
> basis. If there is I'll be much happier and go away a bit wiser.

The only interpretation that would make me happy is one where UTC no longer
requires leap seconds... but that is a different subject.

-Chuck Harris