Phil W Lee wrote:
Martin Burnicki <martin.burni...@meinberg.de> considered Tue, 16 Dec
2014 12:56:15 +0100 the perfect time to write:
William Unruh wrote:
The importance of trades is usually a before/after. And UTC TAI, GPS all
have exactly the same definition of before and after. Of course if one
time was in UTC and the otehr in TAI, that could well be successfully
argued.
From a technical point I absolutely agree with you.
However, there have been discussions (IIRC on the TZ or leapsecs mailing
lists) where folks tried to explain that even though the difference
between TAI and UTC is just an integral number of seconds, TAI could not
even be used as a replacement for UTC without leap seconds, just due to
specific wordings in certain documents.
Leap seconds seem to be a real mess in the IT world.
It would be useful if the way of inserting a leap-second was set in a
standard, in such a way that time continued at a set rate (maybe by
slewing at a set percentage or PPM). If that could be achieved, it
would remove many of the objections to leap-seconds.
It might be difficult to thrash out in practice though.
I know that officially at present there is an additional second
between 23:59:60 and 00:00:00, but no time recording system that I
know of has the ability to record times between 23:59:60 and 00:00:00
correctly (despite such times existing since 1st Jan 1961, which must
surely pre-date any software currently in use), which is a necessary
requirement if the second is to be inserted exactly as currently
specified and time continued forward (so that events are recorded in
the correct order).
Does anyone know of any software which will record times during that
additional second accurately, e.g. as 23:59:60.789?
Yes, different software from Meinberg. ;-)
The main problem is that the underlying system time (often POSIX, which
just counts seconds since an epoch) has the *same* time stamp art the
beginning and end of the leap second.
In order to do the conversion correctly you need to know if the current
second is the leap second, or not, i.e. you need some status flag in
addition to the raw (e.g. POSIX) timestamp.
This is basically similar to what you have at the end of DST, where (in
local time) a whole hour is passed twice. You need to know the DST
status to determine unambiguously if it's the first or the second turn.
Is there any realistic prospect of forcing software to comply with a
time standard which includes times between 23:59:60 and 00:00:00?
Now, you can either stipulate that all software including operation
systems recognise times during that additional second - which would
require re-writing the time functions of most of the worlds software
to recognise and record times >23:59:60 < 00:00:00 (but only if a leap
second has been legally notified), or you can agree to insert the
additional second more gradually by clock slewing (but at what rate
would have to be agreed).
Clock slewing would require much more change to international
agreements, but would require far less work on re-writing software,
and would actually relate better to the real world, which is
annoyingly both analogue AND irregular:-)
Or the second itself could be redefined to take account of the actual
speed the earth rotates - but that might be problematic for the
scientists, as we'd likely have to keep doing it as the earth slows.
I certainly think we need to deal with the problem better than we do
at the moment.
A main reason for the problems with leap seconds is that POSIX has just
ignored them when they defined their standards on timekeeping.
There has been a proposal from David Mills many years ago where the time
during an inserted leap second increases only *very* slowly during the
leap second, so monotonicity of time stamps is kept.
However, most algorithms, or API calls returning a time stamp plus
consistent status information require longer execution time than just
returning a time stamp, e.g. just a 64 bit number. So the easy way is
often preferred over the accurate way.
I've collected some information on leap seconds in a paper which you can
find here:
http://www.meinbergglobal.com/english/info/#whitepaper
Especially:
"Technical Aspects of Leap Second Propagation and Evaluation"
http://www.meinbergglobal.com/download/burnicki/Technical%20Aspects%20of%20Leap%20Second%20Propagation%20and%20Evaluation.pdf
This may not be complete but covers many aspects of leap second handling.
Martin
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
