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<bro...@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@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
