[LEAPSECS] ISO Influence

[Magnus Danielson]

On 12/19/2010 03:43 AM, Warner Losh wrote:

> From: Greg Hennessy<greg.hennessy at cox.net>

> Subject: Re: [LEAPSECS] ISO Influence

> Date: Sat, 18 Dec 2010 19:49:17 -0500

>

>> UTC has leapseconds. If computing doesn't have leap seconds

>> presently, then I would say that computing doesn't have UTC.

>

> time_t, which is how POSIX computers tick time, is aligned to UTC,

> nominally, but doesn't have leap seconds.


If using some method of alignment, such as NTP. Many computers is way off.


> in effect, computers don't have leap seconds.


If they use POSIX, which effectively most computers do.

The POSIX time_t definition then formulates the support of the POSIX 
time support functions, on top of which many computer languages is built 
and their support libraries. It is only fair to assume that they are 
"infected" by this lack of leap-second variant of UTC. Then with this 
basis will many applications built on top of any of these languages 
potentially (or most likely) have issues.

There is however a several ways in which the underlying support for leap 
seconds can be handled, so there is a chance that some applications and 
languages is not affected, and that is when time is stored in some other 
format than time_t and that other format supports or can be made to 
support leap seconds without (significant) changes.
For instance if time is always stored in ISO-8601 format, and full ISO 
8601 parsing is included (it can support leap seconds) then it will not 
require that much of work.

So, if we take the set of all computers and make a sub-set of all 
computer using POSIX (essentially all UNIXes, such as *BSD and LINUX, 
Windows supports it, OSX...) the remaining set contains another sub-set 
division in those that uses POSIX-affected languages in a non-POSIX 
enviroment and the remaining set does not depend on POSIX at all.

The combined set of POSIX machines and POSIX-affected machines will 
cover most of the more complex computers (mobile phones and up) handling 
time (this statement is an assumption from my experience).

This combined set of computers will have an issue with leap seconds.
Many, but not necessary all, applications dealing with time will most 
likely be affected.

Thus, with this hand-waving in mind, it would not be too hard to agree 
that quite likely will a very large set of computers and applications be 
affected as they today lack the support of leap seconds.

This same set of computers would for most reasonable part be unaffected 
by a shift away from leap seconds in the source timekeeping (which UTC 
today). So if UTC drops the leap-seconds and becomes a statically 
time-shifted variant of TAI then these computers will not be affected.

There is however always a small set of specialized applications which 
"knows better" that potentially could be affected by a paradigm shift, 
but there is several cases where they would not see any difference and 
hence not be affected anyway.

So... after my little epidemiological analysis, which I am sure is in 
the back of the heads of several people here, we can conclude that most 
likely will most computers need fixes to support leap seconds, but they 
would not experience any trouble with dropping the insertions of leap 
seconds.

Essentially, the POSIX practice of "papering over" the leap-second 
insertions (which is done only on those computers actually receiving UTC 
time from external source) may cause some hiccups for some applications, 
but it seems like it works good enough not to cause enough damage to 
require a fix.

Re-occurring in this analysis is the condition of the computer system 
being externally fed UTC. Computers not being fed UTC one way or 
another, but is only free-wheeling on its RTC will essentially not care, 
which is part of the POSIX committee reasoning for not adding it.
Computers may have their own RTC free-wheeling away in 86400 s days but 
handle time-data with leap seconds. Some of those applications will be 
transparent to either case, but for many will either leap second support 
simply not be there or such data never be present.
Also notice that for various reasons, such as supporting security 
applications, computers from the not fed with time transitions over to 
the set of computers being fed UTC time, so the field is not static.

It's wont be a quick fix to make sure that they support todays UTC 
behaviour. It will take considerable efforts if being forced through. We 
could come up with a set of tests for a reasonable sensitivity analysis. 
We could roll out test for a number of systems and applications. Any 
bugs would be fixed. We would not find all, but a reasonably large 
amount of them. After that has settled we could then make heavier test 
to make sure we have downed all the bugs, for the systems which really 
needs it. Not many systems have done this.

So "just fixing it" is not a thing to say lightly. It is many systems 
which needs fixing and the rolling out to. Being able to off hand 
identifying them in numbers is a daunting task. No wonders there is 
advocates for dropping the leap seconds in UTC.

Cheers,
Magnus