[LEAPSECS] Standards of time zones -Brooks Harris

[Brooks Harris]

Hi Warner,

Thanks very much, all good points.

On 2014-01-09 05:21 PM, Warner Losh wrote:

> On Jan 9, 2014, at 5:50 PM, Brooks Harris wrote:

>

>> Hi Rob,

>>

>>

>> On 2014-01-09 04:18 PM, Rob Seaman wrote:

>>> On Jan 9, 2014, at 4:58 PM, Brooks Harris<brooks at edlmax.com>  wrote:

>>>

>>>> Well, its clear the "end game" would take a long time to realize. It will take serious patience on the part of folks who care.

>>> We’re halfway there, then ;-)  This conversation has been going on for a very long time.

>> Yes, I know.

>>

>>> Click through to the archives for the current list and for the original leapsecs list from:

>>>

>>> 	http://www.cacr.caltech.edu/futureofutc/links.html

>>>

>>> The place to start before making a foray into the mailing list, however, is with Steve Allen’s excellent pages:

>>>

>>> 	http://ucolick.org/~sla/leapsecs/

>> Yes, I'm aware of and read much of it. Its a great collection of the issues.

>>

>>>> My point is that the standards, where they exist, are dispersed and fractured.

>>> Indeed.  They are also contingent on physical context from the real world.  It is simple fact that a single time scale is insufficient to model the complexity of the systems required.

>> Agreed. But a consistent "civil time" seems to be where the break-downs occur and what has lead to the call to "eliminate Leap Seconds". This is in no small part due to the know inadequacies of POSIX and NTP. So I think some effort to better unify the behavior of "civil time", partly by better documenting UTC's role in "civil time" would go a long way towards relieving this pressure.

> Until leap seconds can be represented in POSIX, and that's an incompatible change, the pressure won't go away. Time in computers simply doesn't understand leap seconds, and many ad-hoc hacks have been necessary to make them mostly cope.

This supports my belief that the "kill Leap Seconds" problem originates 
when "computers", or the computer industry, gets involved. The fact 
computers in general do such an inconsistent job with "civil time" 
derives from the history, including, centrally, POSIX time, since so 
many computer-based time-keeping (OSs, languages, etc) are, or were, 
based on it.

I surmise from the available literature that the reason POSIX doesn't do 
all we'd like is that the systems were rudimentary at the as POSIX was 
first developed and the main objective was only to have a consistent 
counting mechanism. Making that mechanism "close" to, or similar to, 
"civil time" was convenient, even clever.  But "accurate" civil time 
keeping was not really the objective.

I'd make a some points about how POSIX relates to the topic as I 
understand it.

The POSIX counting methods do not account for Leap Seconds directly but 
the assumption is the kernel would supply a "correct" time_t. The POSIX 
spec throws the problem of maintaining "accurate civil time" over the 
wall to the kernel implementation. But I know of no specification or 
guideline of how that should be done.

POSIX is intended primarily to give a forward counting timescale for 
purposes like stamping file-times and such, which it does perfectly well 
for its own purposes if the kernel does the right thing. It does have 
the well known deficiency of "double counts on Leap Seconds" in its 
counting method. This can be overcome only if the kernel somehow informs 
an application that a Leap Second is occurring or has occurred, but 
there's no standard way of doing that.

POSIX emerged from the Unix world. Windows does not implement POSIX 
natively, instead relying on proprietary mechanisms. And here, with 
mention of Windows, the conversation takes on a tone of "OS theology".

I'm more a Windows guy nowadays. This is not by choice, but just that 
customer demands led me deeper and deeper into the Windows world (mostly 
through c/c++).

I'm not religious about it. Once upon a PowerPC time I did a lot of 
Macintosh work. Many friends are Unix/Linux people. I could write a 
three-volume tome titled "Why I Hate Windows". I see all the major OSs 
as fantastic tools. But the unfortunate fact is they are not same, each 
has a different legacy, each has a different culture and ecosystem, and 
its probably impossible for a single person to be expert in all of them.

This has a direct impact on the time-keeping topic because each OS goes 
about it differently. POSIX time was originally designed to be an API to 
the Unix OS, the functionality implemented in the kernel. But Windows, 
by itself, doesn't do POSIX at all. Windows has a proprietary 
time-keeping API (GetSystemTime(), GetFileTime() etc). POSIX is not 
implemented in the Windows "kernel".

In MSVC c/c++ POSIX behavior is available as a sub-system - the POSIX 
API (time_t, time(), gmtime() etc) can be called from time.h (and other 
libs).

Not all of the POSIX time API is implemented in MSVC, for example, 
strptime() and related just do not exist. Further, different versions of 
MSVC (6.0, 2005, 2008, etc) have different implementations, some of 
which are not really POSIX, but extensions of it, particularly extending 
time_t to 64 bit.

If you step into the source code (using the traditional 32-bit version 
in this example) you find the POSIX implementations making calls to the 
Windows APIs. For example, a call to POSIX time() then calls 

::GetLocalTime(), ::GetSystemTime(), ::GetTimeZoneInformation(), and 

__loctotime_t(), making adjustments to (presumably) result in time_t as 
per the POSIX expectation.

Hmmm. Are we believing this result? What if we compare results on 
Windows to results on Linux/GNU?

I recently had a chance to explore that with a colleague. He'd 
implemented some exploratory test code on/in 64-bit Linux/GNU. Well, I 
can't compile his code on Windows - not even close. Whole swaths of the 
POSIX API are just gone missing in Windows c/c++. No way for me to 
duplicate what he'd written.

It becomes clear quickly that if you expect consistent results you 
cannot use the POSIX implementation on *any* platform. You've got to 
implement a complete, comprehensive, time-keeping layer that is entirely 
standalone and portable.

I've done that, mostly, but still struggling with "local time" details. 
And that's where my odyssey through the standards began and where my 
call for a consolidated "standard" document comes from.



> However, something has to give when this happens: Either accuracy in realization of the second, or the monotonic properties of time.

I'm not quite following your meaning here.

> Even worse, intervals across such events get fuzzy as well as calculation of future times is limited to 6 months.

>

> It isn't a lack of understanding that's causing the problems. It is a standardized disconnect.


Yes. But I think much of the "standardized disconnect" has roots in lack 
of understanding in the past. Incomplete consideration of the problem 
resulted in standards containing unfortunate choices which are hard or 
impossible to undo once systems are in the field.

A lot of the disconnect comes from the POSIX spec, and, I hate to point 
this out on this forum where there's a lot of Unix/Lunux folks, a lot of 
the "kill Leap Seconds" fervor seems to radiate from the Unix/Linux IT 
community where POSIX behavior is tangled with the kernel 
implementations. That's not to let Windows or Android off the hook - 
they too, derived as they are from the POSIX tradition too, are flawed 
and contribute to the frustration in computer time-keeping.



> Oh, then there's the whole 'who cares about a second' so many things break in small ways around leap seconds, which makes it hard to get them right.

>

> And then there's the frustration of proposing less insane leap second promulgation that still keeps time in sync, over the long term, but allows for the possibility of DUT1 > 1s (but not unbounded). DUT1 < 1s is only convention and was selected somewhat arbitrarily. .1s was proposed, because that's the threshold of human perception, but that was rejected. After much back and forth, 1s seems to have been accepted because, well, navigation gives only a small error at 1s. The error would be larger at 2s, but still likely acceptable for most things... Announcing leap seconds 10 years out would solve many of the 'nobody knows that it is coming' issues since that would move the timeline of leap seconds from being less than the lifetime of deployed software to being greater than it (in most cases, outliers will still occur). It would also take the time horizon from < 1 year to > 1 year so that managers will know when leaps will happen and won't have to schedule extra, unplanned

>   work.

>

>>>> So, an effort to simply consolidate the terms, definitions, and standards into a single reference document would go a long way toward lending clarity to system implementers, other industries, and, importantly, to governments seeking to refine their laws to coordinate time and commerce with other jurisdictions.

>>> Maybe a reference library is a reasonable place to start rather than a single document.  I’m biased, but not therefore wrong, in recommending the proceedings of the 2011 and 2013 UTC meetings:

>> Well, when I say "document" it might not take the form of a single document - it could be several coordinated publications. My point partly is it needs to created by due-process.

>>

>> nMaybe, just maybe, if enough experts rallied around a common due-process document, then maybe, just maybe, the ITU might take a fresh look at it, and maybe, just maybe, they'd consider refinements to the UTC specs like you've suggested. And maybe, just maybe, the call to kill UTC would fade away.

> Until the operational issues with 'surprise leap second' goes away, and until there's a widely adapted, standardized way to represent time in computers that displaces time_t, I don't think you'll see calls for leap seconds to be improved or go away ending... Basically, the standards have forced great expense to support leap seconds, when in fact an alternative would be for wider DUT1 distribution and integration into systems. Many proprietary systems, alas, won't tolerate this so the astronomers complain that a change like this would idle their telescopes. No comprehensive study has been undertaken to show a balanced approach. To date, I've seen individual impacts of eliminating them from astronomers, but no industry wide study for how much software costs would be saved.

>

> So while I applaud your efforts to get better understanding, I'm pessimistic that it will have the goals you wish to achieve.


You may be right. I explore the suggestion with some trepidation.

I've been involved with standards bodies for a long time. A little rule 
I've noticed might be stated "No technology can be standardized until 
its obsolete".

The other thing I've seen is that when an interoperability problem is 
shared by enough industries, venders, and organizations a critical mass 
can accumulate. Once its recognized to be a general issue and the 
organizations decide to cooperate and tackle it the solution can emerge 
rather quickly. This only happens at extraordinary moments, and with 
dedicated leadership and shepherding.

The topic of "Decoupling Civil Timekeeping from Earth Rotation" and/or 
"Requirements for UTC and Civil Timekeeping on Earth" touches nearly 
everybody on the planet. While I know there are fiefdoms and many 
commercial interests in play I optimistically believe everyone wants to 
solve the problem. Maybe its better to say "everyone wants the problem 
solved".

I'd say POSIX time, *as it stands*, could be seen as obsolete. I'd say 
TAI and UTC need refinement. I'd say definitions and standards 
surrounding "local time" are non-existent.

The passion and expertise on the topic is evident on this list. Could 
this form the nucleolus of a movement?

-Brooks


>

> Warner

>

>>> Decoupling Civil Timekeeping from Earth Rotation:

>>>

>>> 	http://futureofutc.org/2011/preprints/

>>>

>>> Requirements for UTC and Civil Timekeeping on Earth:

>>>

>>> 	http://futureofutc.org/preprints/

>>>

>>> The published proceedings are available from the American Astronautical Society:

>>>

>>> 	http://www.univelt.com/Science.html

>>>

>>> As well as this week’s well attended American Astronomical Society splinter meeting:

>>>

>>> 	http://futureofutc.org/aas223/

>> Thanks very much. I've read some of these and I'll review them all.

>>

>> -Brooks

>>

>>> Rob Seaman

>>> National Optical Astronomy Observatory

>>>

>>> _______________________________________________

>>> LEAPSECS mailing list

>>> LEAPSECS at leapsecond.com

>>> http://six.pairlist.net/mailman/listinfo/leapsecs

>>>

>>>

>> _______________________________________________

>> LEAPSECS mailing list

>> LEAPSECS at leapsecond.com

>> http://six.pairlist.net/mailman/listinfo/leapsecs

> _______________________________________________

> LEAPSECS mailing list

> LEAPSECS at leapsecond.com

> http://six.pairlist.net/mailman/listinfo/leapsecs

>

>