[LEAPSECS] ISO Influence
magnus at rubidium.dyndns.org
Sun Dec 19 03:01:09 EST 2010
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
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.
More information about the LEAPSECS