[LEAPSECS] Crunching Bulletin B numbers (POSIX time)

[Ian Batten]

On 21 Feb 2011, at 03:49, Paul Sheer wrote:


> 

>> 

>> I see that the UK is now cranking up for CET: http://www.bbc.co.uk/news/uk-12517762

>> 

>> Given that most ASCII timestamps are in "local" time, presumably leap

>> seconds are no more evil than changes in timezone: both will throw off

>> the calculations of these hypothetical isolated machines.

>> 

> 

> 

> Local ascii timestamps have a standard way to include GMT offset

> information.


Do you mean GMT offset or UTC offset?  Bang: there's up to a second of ambiguity right there.

And of course, little real software (the legacy you're concerned about) does so, or does so incorrectly.  Exchange issues meeting requests that use GMT to mean UK civil time, even in the summer.   syslogd stores timestamps in logfiles without any zone identifier, relying on the files themselves being monotonically increasing.   dmesg the same (if it includes timestamps at all).   /var/log/cron.   And so on, and so on, and so on.  If Posix is so sensitive to one-second offsets, it's odd how careless it is about one hour offsets?

A search of a Solaris 10 machine reveals precisely one subsystem that logs with zone information: a log called "postrun.log" used by the installation process of staroffice.   Nothing else does --- firewalls, mail systems --- they all log in local time without appending a zone correlator.  Want to perform log analysis between systems in disjoint timezones?  Good luck. 


> So even if the offset is wrong, conversion to and from time_t gives

> back the same result. It merely displays incorrectly.

> 


For gmtime(), perhaps.  For localtime() it clearly can't, because timezones change at a granularity comparable to leapseconds.  And as you're hypothesising systems that aren't updated, that means you're turning a blind eye to (for example) the great presidential election timezone botch, in which Solaris (at least) pre-empted legislation and shipped a zonefile in a major release that kept PDT until early November in years divisible by 4.




> 

> 

> Ascii timestamps do not have a way to include leap second information.


But they trivially could.

> 

> Inclusion of leap second information into ascii timestamps is another

> solution to the leap second problem which I was going to propose.

> 


As you say.  But you'd still need to produce the use case.



> 

> 

> Also, these isolated machines are not hypothetical. Even network

> connected machines are often not time syncronized, yet still deal

> with timestamp data generated by other machines. They are "isolated"

> in that sense.


But if the time isn't synchronised, your elaborate example involving hash tables doesn't work correctly anyway.

ian