[LEAPSECS] Crunching Bulletin B numbers (POSIX time)

[Ian Batten]

On 21 Feb 2011, at 10:19, Poul-Henning Kamp wrote:


> In message <20110221100216.GA9800 at davros.org>, "Clive D.W. Feather" writes:

>> Paul Sheer said:

> 

>>> These systems don't care whether the event really did happen at

>>> 12:34:56pm nor whether the clock was a few minutes slow that day.

>>> 

>>> But they DO care that they are talking about the SAME event!!!

>> 

>> In which case they will have some arrangement to synchronize their clocks.

> 

> You are missing the point.

> 

> If the isolated system creates a file and timestamps it with a time_t

> value of FOO, that translates to a given UTC instant YYYY-MM-DD/HH:MM:SS


No it doesn't.  It translates to a given "Posix UTC" which is roughly equivalent to TAI plus some fixed offset no-one cares to define.  
If I touch a file at XXXX-12-31/23:59:60, which is a perfectly valid UTC instant, God knows what Posix makes of it (presumably XXXX+1-01-01/00:00:00) but whatever it does, it certainly isn't UTC.  And abolishing leapseconds going forward doesn't fix that problem retrospectively.   

However, with or without leapseconds, Posix time is still monotonic both in time_t and , and I would be incredibly dubious of systems that perform interval timing using ctime or localtime or gmtime, rather than the raw time_t.


> That is why, we cannot have some POSIX systems inserting leap-seconds in

> to time_t and some POSIX systems not doing so.


I don't think that's the discussion, is it?    No-one is suggesting that 1SI second after time() returning a value x, time() should or would return anything other than x+1.  The debate is about the semantics of ctime() and gmtime() and locatime(), whether they should assume that timeI() ticked the leapseconds as distinct events.   The Unix machines (ie, real Unix) I've looked at (OSX, Solaris) all state that tm_sec can run 0..60 for gmtime and localtime, so that debate's already on the table.

ian