Re: [LEAPSECS] My FOSDEM slides

[Brooks Harris]

On 2015-03-05 08:39 AM, Martin Burnicki wrote:

Tony Finch wrote:

Martin Burnicki martin.burni...@meinberg.de wrote:


I agree, but as I've tried to point out above I think a better 
project design
would have been to use TAI instead of GPS time. PTP works natively 
with TAI,

and you can easily convert between he two scales.


I don't understand this paragraph. The three timescales you mention have
totally different formats:

TAI: -MM-DD T HH:MM:SS
PTP: SS
GPS:  SS

They have different epochs:

TAI: 1958-01-01 T 00:00:00 Z
PTP: 1970-01-01 T 00:00:00 Z
GPS: 1980-01-06 T 00:00:00 Z

So I don't see how it makes sense to argue that PTP is more like TAI 
than

GPS time.


In the strict scientific sense I agree.

However, in practice, and for current dates, you can convert each of 
them to a number of seconds since the epoch, and for practical 
purposes the difference is just an integral number of seconds.

I agree.

We have seen the casual term TAI-like, meaning an uninterrupted 
incrementing count of seconds from some epoch. PTP and GPS are 
TAI-like in that sense.


For example, the IEEE Std 1588-2008 says:

The PTP epoch is 1 January 1970 00:00:00 TAI, which is 31 December 
1969 23:59:51.18 UTC


However, the time stamps used in the PTP packets are just binary 
numbers of seconds, and you have to apply an integral number of 
seconds to convert this to UTC.


Yes, that's how it must be treated.

I urge caution interpreting the meaning of the PTP Epoch as stated in 
the spec.


The first part of that sentence is correct The PTP epoch is 1 January 
1970 00:00:00 TAI. But the  second part, which is 31 December 1969 
23:59:51.18 UTC, is not, or, is at least very misleading.


This of course begs the all questions regarding a proleptic UTC 
timescale. What, exactly, is that? Did it exist before 
1972-01-01T00:00:00Z (UTC)? Does it include the rubber-band era 
between approximately 1961 and 1972?


The spec goes through long explanations of the relation of its epoch to 
the POSIX algorithm. It wanders through explanation of the 
rubber-band era, and how the broken down time results are obtained 
from gmtime(). This is all wicked confusing. Apparently the IEEE PTP 
committee took UTC to include the rubber-band era, and so attempted 
to reconcile the PTP epoch to it.


In an *informative* Annex B - Timescales and epochs in PTP, there is 
further (confusing) explanation, but then comes Table B.1?Relationships 
between timescales. There we find -


Table B.1?Relationships between timescales

From  | To  |  Formula
NTP Seconds   | PTP Seconds | PTP Seconds = NTP Seconds ? 2 208 
988 800 + currentUtcOffset
PTP Seconds   | NTP Seconds | NTP Seconds = PTP Seconds + 2 208 
988 800 ? currentUtcOffset

GPS Seconds = | |
(GPS Weeks| |
× 7 × 86 400) | |
+ GPSSecondsInLastWeek| |
(GPS week number must | |
include 1024 × number | |
of rollovers) | PTP Seconds | PTP Seconds = GPS Seconds + 315 
964 819
PTP Seconds   | GPS Seconds | GPS Seconds = PTP Seconds ? 315 
964 819


All the values in this table are *integral seconds* and they are correct 
with respect to the definitions other timescale Epochs. (They neglect to 
say the values for NTP are to NTP's prime epoch of era 0, a subtle but 
important point)


These are the values you must use for a practical implementation of PTP, 
and that is the convention adopted by the PTP community. These values 
*contradict* the second part of the epoch specification sentence 
(...which is 31 December 1969 23:59:51.18 UTC) and all the rest of 
the PTP epoch explanations throughout the document.


The rubber-band era, while historically important, is just not 
relevant to practical timekeeping applications concerned with modern UTC 
and civil time. The scattered nature of the UTC specifications lead 
from UTU-R Rec 460 to BIPM Annual Report on Time Activities Tables 1 and 
2 that list the historical values of the rubber-band era. This leads 
to attempting to figure out what the historical values of UTC were 
during this period. Its interesting, but its a huge distraction until 
you realize it doesn't matter for most purposes. Like many of us, the 
IEEE PTP committee fell into this trap.


You can construct a Gregorian calendar timescale that is proleptic to 
1972-01-01T00:00:00Z (UTC) = 1972-01-01T00:00:10Z (TAI) (note the 10s 
TAI/UTC offset) and treats the measurement unit as integral seconds. 
This is, I believe, is the timescale most often used to calculate 
offsets between timescales, but is never explicitly acknowledged or 
named. Here I'll name it Gregorian proleptic to UTC1972.


With that you can reconcile the offsets between the epochs of NTP, TAI, 
PTP, POSIX, UTC, and GPS in integral seconds.


-
Origin  

Re: [LEAPSECS] epoch of TAI, and TAI vis a vis GPS

[Brooks Harris]

On 2015-03-03 09:23 PM, Steve Allen wrote:

On Wed 2015-03-04T00:04:10 +, Tony Finch hath writ:

They have different epochs:

TAI: 1958-01-01 T 00:00:00 Z
PTP: 1970-01-01 T 00:00:00 Z
GPS: 1980-01-06 T 00:00:00 Z


Using ISO 8601 style date and time representation on the TAI timescale 
and on the UTC timescale before 1972-01-01T00:00:00Z (UTC) is dangerous 
without qualification or explanation.


The Z implies its on the UTC timescale. It is controversial when the 
term UTC came into use. It is controversial if the UTC timescale 
existed prior to 1972-01-01T00:00:00Z (UTC), and if it did, exactly what 
it is..


TAI: 1958-01-01 T 00:00:00 Z  - By preceding it with TAI we guess 
you mean the TAI timescale if we ignore the Z.
1958-01-01T00:00:00 (TAI) is the origin of the TAI timescale, as per 
ITU-R Rec 460.
Using pure Gregorian calendar counting method, 1958-01-01T00:00:00 (TAI) 
is exactly (1972-1958 = 14 years * 365 = 5110 days + 3 leap year days = 
5113 days * 86400 seconds = 441763200 seconds) before 
1972-01-01T00:00:00 (TAI).


PTP: 1970-01-01 T 00:00:00 Z - The PTP Epoch is defined as 
1970-01-01T00:00:00 (TAI) *on the TAI timescale*. Using pure Gregorian 
calendar counting method, 1970-01-01T00:00:00 (TAI) is exactly 
(1972-1970 = 2 years * 365 = 730 days + 0 leap year days = 730 days * 
86400 seconds = 63072000 seconds) before 1972-01-01T00:00:00 (TAI).


GPS: 1980-01-06 T 00:00:00 Z - The GPS Epoch is properly and firmly on 
the UTC timescale, after 1972-01-01T00:00:00Z (UTC). There's no 
controversy there. The GPS Epoch is 1980-01-06T00:00:00Z (UTC) = 
1980-01-06T00:00:19 (TAI). From there they count in uninterrupted weeks.


Meantime (always fun to use that expression in a discussion of 
timescales :-) ), POSIX the epoch is stated as January 1, 1970 
Coordinated Universal Time (UTC). It is controversial if UTC existed 
before 1972. So, to get to that date from 1972-01-01T00:00:00Z (UTC) = 
1972-01-01T00:00:10 (TAI) we need to constuct some proleptic timescale 
before 1972-01-01T00:00:00Z (UTC). I'm not sure what we'd like to call 
this proleptic timescale, lets call it POSIX for now. Using Gregorian 
calendar counting, 1970-01-01T00:00:00 (POSIX) is (1972-1970 = 2 years * 
365 = 730 days + 0 leap year days = 730 days * 86400 seconds = 63072000 
seconds) before 1972-01-01T00:00:00Z (UTC).


Similarly for NTP. RFC 5905 states .. the prime epoch, or base date of 
era 0, is 0 h 1 January 1900 UTC. Again, lets call this proleptic 
timescale NTP. So, 1900-01-01T00:00:00 (NTP) is (1972 - 1900  = 72 
years * 365 = 26280 days + 17 leap year days = 26297 days * 86400 
seconds = 2272060800 seconds) before 1972-01-01T00:00:00Z (UTC).


Our POSIX timescale overlaps our NTP timescale - they exist on the 
same timescale proleptic to 1972-01-01T00:00:00Z (UTC) using the the 
Gregorian calendar counting method. I got flamed for calling it 
proleptic UTC. What should it be called? After all its used all the 
time, shouldn't we have a name for it?



Getting meaninglessly pedantic, in Survey Review v19 #143 p7 (1967)
A.R. Robins had been talking with Sadler and Smith and with that
information in hand he wrote that atomic time was identical to UT2 at
1958-01-01 T 20:00:00 Z
ITU-R Rec 460 says TAI .. from the origin 1 January 1958 (adopted by 
the CGPM 1971).


In 'Metrologia - leap second: its history and possible future' - 
http://www.cl.cam.ac.uk/~mgk25/time/metrologia-leapsecond.pdf - we read:
In conformity with the recommendations of IAU Commissions 4 and 31 in 
1967, the CCDS [80] defined the origin so that TAI would be in 
approximate agreement with UT2 on 1 January 1958, 0 h UT2. The 14th CGPM 
approved the establishment of TAI in 1971.


As I interpret this, while there were previous historic uses of 
1958-01-01 as an epoch for various things, including LORAN and early 
development atomic timescales, TAI didn't officially exist until 1971, 
and by adopting 1958-01-01T00:00:00 (TAI) as the TAI origin they 
acknowledged those precedents and made the definition specific and 
official on the TAI timescale. Whatever the values or accuracies may 
have been for previous 1958-01-01 epochs, this act established the 
modern version accurately tied to the TAI timescale.


Is that how you see it?



This, of course, disagrees with Guinot's memoir, but the various
realizations of UT2 then differed by centiseconds and the different
versions of atomic time were subsequently realigned by milliseconds.
And that date of 1958-01-01 was decided ex post facto at the 1959
August meetings where the US and UK decided to try coordinating their
broadcast time signals using cesium.  So there really isn't an epoch
for TAI.

Seems to me there is, as above.



On Tue 2015-03-03T14:31:13 -0800, Hal Murray hath writ:

Since GPS time is a fixed offset from TAI, it's easy to convert.

I believe that BIPM would disagree because of the different kinds of
steering at the nanosecond level.  The stance of the BIPM was expressed in

Re: [LEAPSECS] My FOSDEM slides

[Brooks Harris]

On 2015-03-04 02:12 AM, michael.deckers via LEAPSECS wrote:


   On 2015-03-03 21:05, Martin Burnicki wrote about
   negative leap seconds:

 In the 7 year interval where no leap second was required/scheduled I 
heard

 several people saying we might have needed a negative leap second.


   Fortunately, this is not a matter of speculation. An easy way to
   see the trend of UT1 - UTC is to look at DUT1 (published in
   Bulletin D). DUT1 is an approximation to UT1 - UTC and has
   always stepped down (except, of course, at positive leap seconds),
   ever since the earliest Bulletin D available on the web (1991-06-20).

   Before a negative leap seconds would be scheduled, we would see
   DUT1 stepping up several times in a row, so there _is_ some
   advance warning.

We can't predict the future. It's fascinating to read about the many 
factors affecting Earth's rotation. It seems the largest one is the one 
we know least about - the Earth's core. I wonder what DUT1 would have 
looked like around the time of the Chicxulub impactor.


Negative Leap Seconds have been a feature of the specification since the 
beginning. It gives a little more margin to accommodate the unknown, and 
it's not an onerous complication. I hope we concentrate on helping get 
implementations to conform to the UTC specs as they stand rather than 
look for justifications to over simplify the problem.


-Brooks


Michael Deckers.

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Civil timekeeping before 1 January 1972

[Brooks Harris]

Hi Steve,

On 2015-03-07 03:01 PM, Steve Allen wrote:

On Sat 2015-03-07T14:14:07 -0500, Brooks Harris hath writ:

It is typically warned that date and time before 1972 cannot be
accurately represented with NTP or POSIX, for examples.

I would say that for PTP
* all seconds are always SI seconds
* seconds after 1972-01-01 correspond to (TAI - 10)
* seconds before 1972-01-01 do not align with civil time
* in particular, 1970-01-01 in PTP does not correspond to
   any event in any time scale which was then in use,
   but that does not matter
For PTP it is the uniformity going forward that is the goal.
Keep in mind PTP is for .. Networked Measurement and Control Systems, 
so its first objective is for things like process control, hence its 
primary timescale is TAI-like. Civil time, or UTC, is a secondary 
concideration, but it has mechanisms to communicate UTC 
(currentUtcOffset, leap59, leap61). It does not specify the UTC rules by 
which these are set, relying on the UTC background specifications for that.


leap59 and leap61 are Leap Second announce signals, set 12 hours prior 
to the insert. There has been discussion about when the official 
announcements and expiration should be announced. ITU Rec 460 says 
...at least eight weeks in advance. PTP can't do that, a point to keep 
in mind.



I would say that the intent NTP and POSIX is to correspond to civil
time in contemporary use.  Therefore, for dates before 1972-01-01
NTP and POSIX are counting seconds of UT.
First let me compliment you on all your excellent work and research at 
http://www.ucolick.org/~sla/leapsecs/. This is an invaluable resource 
and I have learned much from it. Thank you.


This paragraph in your email had me scratching my head a little. So, 
first, off to your time pages to learn more carefully about UT. I think 
I see what you mean generally.


My view is the NTP and POSIX are abstract timescales constructed for 
convenient civil timekeeping calculation, albeit with their Leap 
Second flaws. I think I would suggest your statement would be better as 
 .. for dates before 1972-01-01 NTP and POSIX are counting seconds on a 
proleptic scale that extrapolates the SI Second prior to 1972-01-01..


This seems clear epecially in NTP, where RFC 5905 states It should be 
noted that strictly speaking, UTC did not exist prior to 1 January 1972, 
but it is convenient to assume it has existed for all eternity, even if 
all knowledge of historic leap seconds has been lost.


It seems to me NTP and POSIX as well as other timescales concerned with 
civil time, are essentially disconnected from reality, expressing 
idealized measurement scales. UTC is an idealized scale expressing an 
approximation of reality derived from UT1, and UT1 will probably always 
undergo some refinement and the sciences advance. I think none of the 
civil timescales are counting in UT - they are measured in SI Seconds, 
even when prolpetic to 1972.


Am I missing something here?



For dates after 1972-01-01 I would say that NTP and POSIX are both
confused

You bet


about whether they are counting SI seconds or UT days.
Can you be more specific about what you mean by this? I think I 
understand your general meaning, that the confusion, or the mis-match 
between the NTP and POSIX and UTC, lies with their methods of accounting 
for LOD. By UT days do you mean 86400 seconds per day?



Therein, of course, lies the basis of this LEAPSECS list.


Sure. Well, at least, therein lies *one reason* for this LEAPSECS list. :-)


I see it as inevitable that the confusion must end, therefore NTP and
POSIX will eventually be unambiguous that they are counting SI
seconds.  That means that, eventually, any general purpose time scale
intended to correspond to civil time will be a piecewise continuous
time scale.  Such general purpose time scales will have a date at
which they switch from counting UT days to counting SI seconds.

Deciding on that date, and how it will be implemented and understood,
is what we hope the ITU-R will accomplish at WRC-15.
Can you elaborate on this point as you've stated it? What exactly do you 
mean switch from counting UT days to counting SI seconds? This doesn't 
sound quite like what I understand the question(s) at WRC-15 to be.





For date-time before 1972 you've got to switch to some
other timescale depending on the purpose at hand.

Exactly so.  Before 1972 civil time was not SI seconds.


I understand the proper SI second sprung into existence as of 1972. But 
it seems to me civil time as kept by NTP and POSIX before 1972 is 
measured in proleptically exrapolated SI seconds. Of course this scale 
does not correspond with actual historical date and time or UT1. What 
am I missing?


Thanks,

-Brooks


--
Steve Allens...@ucolick.org WGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165Lat  +36.99855
1156 High StreetVoice: +1 831 459 3046   Lng -122.06015
Santa Cruz, CA 95064http

Re: [LEAPSECS] Civil timekeeping before 1 January 1972

[Brooks Harris]

On 2015-03-07 06:50 PM, Joseph Gwinn wrote:

On Sat, 07 Mar 2015 14:14:07 -0500, Brooks Harris wrote:

In the discussions I've been involved with many people argued
strenuously we don't care about the past, only accurate date-time
going forward!. The reason I'm choosing to ignore the subject of
accurate date-times before 1972 is not that its not important, but
probably the same reason its side-stepped by NTP, PTP, POSIX, and GPS
- its just too expansive a topic to tackle in some commonly accepted
way. For date-time before 1972 you've got to switch to some other
timescale depending on the purpose at hand.

I figured it out the difference between GMD and UTC for POSIX.  There
was an 81 microsecond error,  At the time, most UNIX boxes kept time to
the nearest second, synchronized to a hairy wrist.  There were advanced
systems that could do milliseconds, and in the 1980s a few that had
microsecond resolution, but we chained them to GPS via NTP, so the
error was multiple milliseconds, depending on everything.

Hi Joe,

I see the difficulties with UTC implementations and the questions at 
ITU-R stemming from the historical and legacy misalignment of the 
timekeeping mechanisms of the c language and POSIX and the UTC 
specifications. Perhaps that's obvious. I'm not criticizing anybody 
anywhere for this, its just the way its come about.


I think the only way the industry can eventually converge on reliable 
civil time representation is to refine the underlying time mechanisms 
in POSIX in some manner that allows a migration to a more comprehensive 
UTC implementation. I think if a new new POSIX time specification were 
to take shape it would add an option to the the conversation at ITU-R - 
instead of simply to kill Leap Seconds or not they'd also have a 
viable migration path to comprehensive UTC timekeeping implementation 
to consider.


We understand the folks at POSIX have grappled with this topic in the 
past and run into all sorts of difficulty. Given the current state of 
affairs, do you think there's any way IEEE and POSIX could reengage this 
topic?


-Brooks



Joe Gwinn
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Bulletin C and all that

[Brooks Harris]

On 2015-01-25 04:57 PM, G Ashton wrote:

Brooks Harris mentioned, at approximately Sun 1/25/2015 21:02 UT, a
Gregorian timescale. I believe that since in Gregory's time there was no
alternative to making the passage of calendar days agree with the day/night
cycle, we must understand Gregorian timescale to mean either apparent or
mean solar time (unless an ecumenical council is called and declares
otherwise). Also, I am not at all sure that the Gregorian calendar has
always been used together with the convention that the new day begins at
midnight; I would like to be pointed to a reference that says that, if it
exists.


ISO ISO 8601:2004(E), 3.2.1 The Gregorian calendar
-Brooks



Gerard Ashton

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Bulletin C and all that

[Brooks Harris]

On 2015-01-25 08:15 PM, G Ashton wrote:

Rob Seaman wrote:


Interesting if UTC can indeed be said to have implemented two different

mechanisms whose entire point was to keep Universal Time synchronized with
Mean Solar Time.

The point of the multiple mechanisms was to keep UTC close to UT which is
mean solar time at Greenwich, or wherever zero degrees longitude is deemed
to be.

Rob Seaman also wrote:

Leap seconds are introduced at midnight UTC, not when TAI modulo 86400

equals zero.

  I would think that midnight UTC is the instant when the UTC time becomes
00:00:00. I would call the introduced second the one that began at 11:59:60
and ended one second later at 00:00:00.


Yes. That's what ITU-R  TF.460-6 says. Its made very clear in Annex 3.

-Brooks



Gerard Ashton

-Original Message-
From: LEAPSECS [mailto:leapsecs-boun...@leapsecond.com] On Behalf Of Rob
Seaman
Sent: Sunday, January 25, 2015 19:26
To: Leap Second Discussion List
Subject: Re: [LEAPSECS] Bulletin C and all that

On Jan 25, 2015, at 1:03 PM, Stephen Scott stephensc...@videotron.ca
wrote:


Since UTC is defined by the IERS before 1972-01-01 beginning_of_utc is

not appropriate.

This is the beginning of integer leap seconds, not UTC.

Contributors to this list can always count on prompt fact checking ;-)  That
said, the IERS came later than that, didn't it?

Interesting if UTC can indeed be said to have implemented two different
mechanisms whose entire point was to keep Universal Time synchronized with
Mean Solar Time.


How about leap_second_epoch or if the term epoch is undesirable

leap_seconds_origin labelled as leap00

Ok, I'll re-index to leap0 and have a new cname called origin.leapsec.com.
How's that?


On Jan 25, 2015, at 2:01 PM, Brooks Harris bro...@edlmax.com wrote:


TAI is often also represented as a date-time but there is rarely a clear

distinction made about what it means.

TAI is most naturally expressed as an unending tally of SI-seconds.  UTC as
a sexigesimal fraction of a solar (synodic) day.  It is conversion between
the two concepts that get us into trouble.  This DNS scheme might provide a
small step toward letting them live together in greater harmony, and the
tzdist standard a larger step addressing additional use cases.


And, Rob, what, exactly, does 1972  1 mean in your Leap Seconds table?

1972-01-01T00:00:00 (TAI) or 1972-01-01T00:00:00Z (UTC)?

As PHK has observed, the essential concept of the IPv4 DNS leap second
coding is to express the equivalent of Bulletin C.  I have always
interpreted the independent variable of the IERS table as UTC.  Leap seconds
are introduced at midnight UTC, not when TAI modulo 86400 equals zero.

Rob

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Bulletin C and all that

[Brooks Harris]

I agree with Michael.

The (proper) UTC timescale does not exist before 1972-01-01T00:00:00Z 
(UTC). That's the beginning of modern (solar) time. There was, or is, 
*by definition*, an initial 10 (integral!) second TAI-UTC offset at that 
moment. There is no agreed on a term for these initial 10 seconds - they 
are usually lumped into the term Leap Seconds - but that's misleading 
because the first real Leap Second occurred at (of course, actually 
immediately before) 1972-07-01T00:00:00Z (UTC).


Meantime, the epochs of NTP and POSIX are defined in terms of UTC, but 
before 1972-01-01T00:00:00Z (UTC). They exist on a timescale I've been 
flamed for calling proleptic UTC. This a timescale that extrapolates 
the Gregorian calendar counting method *uncompensated for Leap Seconds 
or anything else* into the (indefinite?) past before 
1972-01-01T00:00:00Z (UTC).


Note I've carefully qualified my character representation of date-time 
with the suffix (UTC). (By the way, why is there no accepted term for 
the idea of calendar date and time-of-day together, I wonder?) This 
because TAI is often also represented as a date-time but there is rarely 
a clear distinction made about what it means. Generally, one assumes the 
TAI timescale as represented as a date-time must be the Gregorian 
calendar counting method *uncompensated for Leap Seconds or anything 
else* because, of course, TAI certainly has no Leap Seconds.


ITU-R  TF.460-6 says -
BInternational atomic time (TAI)
... from the origin 1 January 1958 (adopted by the CGPM 1971).

What, do you suppose, does 1 January 1958 actually mean? I guess it 
can't be on some proleptic UTC timescale because UTC doesn't yet 
exist, so it must be on an uncompensated Gregorian calendar timescale, I 
think. So I'll represent this as 1958-01-01T00:00:00 (TAI), with the 
suffix (TAI) to be sure there's no confusion with (UTC), and to 
indicate its a representation of the TAI timescale as an *uncompensated* 
Gregorian calendar timescale.


So, how many (integral) seconds between 1958-01-01T00:00:00 (TAI) and 
1972-01-01T00:00:00 (TAI)?


1972-1958 = 14 years * 365 = 5110 days + 3 leap year days = 5113 days * 
86400 seconds = 441763200 seconds.


So now the tricky question - how many (integral) seconds between 
1958-01-01T00:00:00 (TAI) and 1972-01-01T00:00:00Z (UTC)?


http://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat says -

#MJDDateTAI-UTC (s)
#   day month year
#-----   --
#
41317.01  1 1972   10

What, exactly, does this mean? Do we interpret the MJD value as 
uncompensated Gregorian calendar, or should the conversion include the 
10 second initial offset somehow? What does 1  1 1972 mean, exactly? 
1972-01-01T00:00:00 (TAI) or 1972-01-01T00:00:00Z (UTC)?


So, again, how many (integral) seconds between 1958-01-01T00:00:00 (TAI) 
and 1972-01-01T00:00:00Z (UTC)? Is it 441763210 seconds or 441763190 
seconds? Put another way, is the UTC epoch 1971-12-30T23:59:50 (TAI) = 
1972-01-01T00:00:00Z (UTC)? Or 1972-01-01T00:00:10 (TAI) = 
1972-01-01T00:00:00Z (UTC). Or should it be represented as 
1972-01-01T00:00:00 (TAI) = 1972-01-01T00:00:00Z (UTC)?


I believe the correct answer is 441763210 seconds, or 
1972-01-01T00:00:10 (TAI) = 1972-01-01T00:00:00Z (UTC). I believe this 
because its consistent with other implementations. But, to tell you the 
truth, I'm not 100 percent sure - I really can't figure it out from the 
official specs Rec 460, BMPI and/or IERS because they never say what the 
heck they mean by their date representations.


I've seen many implementations that do not agree by 10 or 20 seconds, 
indicating I'm not the only confused reader. So I'm curious, what do 
other self-declared experts here on the list believe? What, exactly, is 
the origin or epoch of the UTC timescale?


And, Rob, what, exactly, does 1972  1 mean in your Leap Seconds table? 
1972-01-01T00:00:00 (TAI) or 1972-01-01T00:00:00Z (UTC)?


-Brooks



On 2015-01-25 12:00 PM, Michael Deckers via LEAPSECS wrote:


  On 2015-01-25 14:58, Rob Seaman wrote:


 Please let me know about typos, suggestions, etc.  Needless to say this

  remains a prototype.
...

 MM before  after  encoded crc IP  Decodedflags
 
--
1972  1  9 10 f8000a00  f5 248.0.10.245- OK 1972  1  10  
1  (1, 0)


  It would be incorrect to consider the discontinuity of the difference
  TAI - UTC at the epoch when TAI was 1972-01-01T00:00:10 as a leap 
second;
  the difference increased by about 0.108 s, not by 1 s. Hence, a 
timestamp

  such as 1971-12-31T23:59:60.2Z should not be made acceptable.

  The first leap second occurred when UTC reached 1972-07-01; the 
information
  about a leap second says something about TAI - UTC both before and 
after
  the date referenced. At 1972-01-01, however, the information can 
only say

  something about TAI 

Re: [LEAPSECS] stale leap second information

[Brooks Harris]

On 2015-01-13 01:44 PM, Hal Murray wrote:

If I understand the provenance, BIPM is responsible for maintaining  atomic
time and TAI, IERS is responsible maintaining for UT1 and Leap  Seconds, and
ITU is responsible for time dissemination. Whats not so  clear, and it
would be reassuring to know, is how the information is  officially shared
between these bodies and to what degree its automated.

I don't think the ITU does any actual dissemination.  They don't run any
servers or radio transmitters.


Right. They are a standards body -

ITU-R  Radiocommunication Sector (ITU-R)

Our mission is to ensure the rational, equitable, efficient and 
economical use of the radio-frequency spectrum by all radiocommunication 
services, including those using satellite orbits, and to carry out 
studies and approve Recommendations on radiocommunication matters.


http://www.itu.int/en/ITU-R/Pages/default.aspx



I picture the ITU as a level higher than that.  They coordinate things like
We all agree to use leap seconds


.. the way Rec 460 says

ITU-R Recommendation TF.460
Rec. ITU-R TF.460-6, Standard-frequency and time-signal emissions
http://www.itu.int/rec/R-REC-TF.460/en



and BIPM will figure out when they happen.


The IERS will figure out when they happen.

IERSInternational Earth Rotation and Reference Systems Service

The primary objectives of the IERS are to serve the astronomical, 
geodetic and geophysical communities by providing data and standards 
related to Earth rotation and reference frames.


http://www.iers.org/nn_10880/IERS/EN/Organization/About/about.html?__nnn=true


-Brooks





___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Google, Amazon, now Microsoft

[Brooks Harris]

On 2015-06-03 10:55 AM, Poul-Henning Kamp wrote:



In message 556f0c92.4020...@edlmax.com, Brooks Harris writes:


You're saying this to the bloke who implemented a prototype adaptive
optics solution for the ESO ELT on a plain, unmodified FreeBSD
kernel ?

I didn't know that, very impressive. Is there information anywhere how
it was done?

I did a presentation at a workshop at ESO in december 2012, the
slides seems to be here:

 https://www.eso.org/sci/meetings/2012/RTCWorkshop/proceedings.html

Oh great! On quick glance that's just the sort of RT discussion I was 
interested in. I'll study it more.

I'm not sure what the legal status is for deeper info.  You'd have
to ask them for access.  The person to talk to is Nick Kornweibel.

And dig deeper when I can.

I bring the RT aspect [...]

The first point here is that commodity *NIX, be it LINUX, FreeBSD
or something else is often used to pull time into systems, even
if they themselves don't do the RT part.
Yes, right, as I said, if not so clearly, some sort of hardware 
assist. In my land we have things like SDI, perhaps on PCI, feeding 
video/audio in real-time, or device control (remote control of 
video/audio devices) protocols that arrive at serial ports (COM or USB 
or something) in real-time. Those sources often have high quality 
oscillators and timebases and the protocols support deterministic 
delivery to the port. You then have to carefully interface through 
worker threads and buffers to hang the timestamps on the video/audio 
samples, etc. That can be tricky, and often involving the manufacture's 
NT device drivers (some work better than others!), or you may need to 
build a driver yourself, notoriously tricky, but down there you can get 
really close to the metal (ring 0) if you're careful. But its never an RTOS.




The other thing to notice is that even if it is not RT in the strict
classical sense, commodity *NIX does things which matter on
microsecond resolution timescales.  (As for instance the ESO thing).

Right. Thanks,




The time on Microsoft Azure will be Different by a second, everywhere
http://www.theregister.co.uk/2015/05/29/windows_azure_second_out_of_sync/

As I said earlier - A) Where did they get this information? B) Is it
true? C) Is that how Windows is behaving?

A) Ask them.

Can try.

(M$ probably notified their customers ?)

They did -

How the Windows Time service treats a leap second
https://support.microsoft.com/en-us/kb/909614



B) I have no reason to doubt it.  The Reg is usually very good on truth.

I doubt it now -

Contrary to one post I recently read, Microsoft doesn’t implement a 
leap second time zone by time zone – in other words, in a rolling 
fashion, like the way we watch new year celebrations count down around 
the world. Essentially, the leap second occurs at the same time 
everywhere.


Another look at the impact of the coming 2015 leap second (not much)
http://blogs.msdn.com/b/mthree/archive/2015/06/01/2015-leap-second-060115.aspx 



Also How the Windows Time Service Works
https://technet.microsoft.com/en-us/library/cc773013(v=ws.10).aspx



C) Probably only in Azure.

As above, I doubt it.

Other Windows will probably do the
usual Windows thing:  Step a second some time later.
Yes. It looks like it can be kept pretty close with a careful use of 
Windows Time Service, but thats not usually active on typical machines.


Leap Seconds are not the only thing might upset the apple cart -

Summary of Windows Azure Service Disruption on Feb 29th, 2012
http://azure.microsoft.com/blog/2012/03/09/summary-of-windows-azure-service-disruption-on-feb-29th-2012/

-Brooks




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Google, Amazon, now Microsoft

[Brooks Harris]

On 2015-05-31 04:40 AM, Poul-Henning Kamp wrote:


In message556abecf.2050...@edlmax.com, Brooks Harris writes:


My question is, if Azure is doing this, what is Windows itself doing?

No.


for that no new information is available and the most recent
guidance was that somewhere between a second and an hour later
the clock will step a second.

most recent guidance from whom?

As I understand it, the clock would step a second when it syncs with
NTP, but note there are apparently different capability NTP clients in
various Windows versions. But what happens in different timezones?

Most Windows boxes don't run NTP.
I don't think that's true. As far as I know, Windows, either personal or 
Server versions, synchronize using NTP, and did so with SNTP until Win 
2000, then NTPV3, then NTPV4. I glean this from accumulated knowledge - 
its difficult to find authoritative information from Microsoft about it.


Where Servers and Windows Time Service are concerned, this is the best 
explanation I've found -


Disrupting time management in a Microsoft Windows 2008 Active Directory 
environment using NTP

https://www.os3.nl/_media/2012-2013/courses/ssn/disrupting_time_management_in_a_microsoft_windows_2008_active_directory_environment_using_ntp.pdf

There are good reference in that article.

There are more recent articles pertaining to Server versions, where 
Active Directory and the Windows Time Service (the W32Time (Windows 
Time) service) are in use.


How the Windows Time Service Works
https://technet.microsoft.com/en-us/library/cc773013(v=ws.10).aspx

On my personal laptop running Win 7, I don't have Active Directory, and 
the W32Time service is *not* started. But it will synchronize via the 
usual desktop Internet Time mechanisms. It uses either 
time.nist.gov, time.windows.com, etc. These are NTP servers.



Some of them run some oddball M$ time-sync protocol where they ask
their domain-controllers -- if they have one.
As above - the domain controller is configured or discovers an NTP 
server. The NT5DS protocol routes the NTP through the domain controller.


Where domain-controllers get their time is anyones guess.

As above - an NTP server as configured or discovered.

Windows of any version is fundamentally following NTP.

But that doesn't answer the first question about how the Leap Second is 
applied to local time by Azure and/or Windows.


Also -

NIST Internet Time Service (ITS)
http://www.nist.gov/pml/div688/grp40/its.cfm

The story around Leap Seconds and Windows: It’s likely not Y2K
http://blogs.msdn.com/b/mthree/archive/2015/01/08/leap-seconds-010815.aspx

Part two of the story around Leap Seconds and Windows: #NotY2K
http://blogs.msdn.com/b/mthree/archive/2015/01/14/leap-seconds-011415.aspx

-Brooks






___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Google, Amazon, now Microsoft

[Brooks Harris]

Hi Poul-Henning,

On 2015-05-31 03:33 PM, Poul-Henning Kamp wrote:


In message 556b5d76.6000...@edlmax.com, Brooks Harris writes:


Most Windows boxes don't run NTP.

I don't think that's true. As far as I know, Windows, either personal or
Server versions, synchronize using NTP, and did so with SNTP until Win
2000, then NTPV3, then NTPV4. I glean this from accumulated knowledge -
its difficult to find authoritative information from Microsoft about it.

So that depends what you mean by NTP.

If you mean that your packets look like NTP packets, then yes, it does
run NTP.

OK.

But I mean use the NTP clock model.
Right. OK, well, its not made clear exactly what it does with its 
counting over the Leap Second (like NTP freeze or POSIX reset) or 
how its applied to local timescales. .



On my personal laptop running Win 7, I don't have Active Directory, and
the W32Time service is *not* started. But it will synchronize via the
usual desktop Internet Time mechanisms. It uses either
time.nist.gov, time.windows.com, etc. These are NTP servers.

But what happens when the leap-second hits ?

Most likely, at some random time after the leapsecond, your clock
steps a second.

Right, for normal personal computers. Severs may be more tightly synched.



Windows of any version is fundamentally following NTP.

Not even close.
Well, what I mean its it relies on NTP for its time in some way or 
other. I didn't mean it *is* NTP, so I'll retract the comment in that form.


That's why Meinberg still maintains their NTPD client.
Right. The discussion didn't start out about accuracy, but about the 
counting rules.


You should find Martins presentation from FOSDEM about this.


But that doesn't answer the first question about how the Leap Second is
applied to local time by Azure and/or Windows.

Because that is the only sane thing for them to do, given the (broken)
timekeeping in the software they run.
Well, broken in what way for what purpose? An awful lot of people use 
it.. Its time is not precise and/or accurate without some help from 
somewhere, but its good enough to have become the largest platform. I 
could write a three volume tome on Why I Hate Windows. But its the 
environment, like it or not.


The fundamental question about leapseconds is not about where Rob can
find the sun at noon, but about teaching an awful lot of rather crap
programmers how to cope with a infrequent and intractable complexity
on short notice.
I don't think its fair to insult all the programmers. Timekeeping is a 
specialty, and a controversial specialty. Most programmers are trying to 
use system timekeeping services on various platforms and applications 
that are not well documented, and often flawed. The fact there are bugs 
is no surprise and until a concerted effort is made to improve the 
underlying standards and implementations it will be a trash..


It seems like Daniels scheduling on this one may show us which is more
important.

Sorry, lost track of what that comment refers to..

-Brooks

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Google, Amazon, now Microsoft

[Brooks Harris]

Hi Tom,

On 2015-05-31 07:23 PM, Tom Van Baak wrote:

Hi Brooks,

I don't know enough about Windows timekeeping in general or versions of Windows 
in particular to give you any authoritative answer. But here's one data point 
that might help clarify what you and PHK are talking about.

On Windows XP, click on the clock icon and look at the Internet Time tab. It says my 
laptop will sync against time.nist.gov (choice of nist or microsoft) automatically once 
a week (no choice). You can also manually initiate a sync.
Right. There are more choices on more recent Windows versions (Vista, 7, 
8..). And the Server versions have more choices with Windows Time 
Service turned on.


I looked at the LAN packets during the weekly sync and it consists of a single 
NTP packet going out and a single reply coming back. See attached snapshot.

So, yes, Windows uses an NTP packet. But, no, it doesn't run NTP.
Well, it must have an NTP client application to initiate the connection 
and communicate to the NTP server, no?


This one looks to be NTPv3.

I've implemented an SNTP client on Windows and it behaves very much like 
the standard Internet Time.




Multiply this by 250 million [1] PC's still happily running XP and you can 
better understand why Microsoft hasn't been that interested in leap seconds, 
NTP, or participating in the hh:59:60 timestamp nightmare.
Yes, they've got a very large number of badly administrated systems in 
the field. In more tightly administrated systems it can be done better. 
But its all good enough for current purposes.



It would make sense, like Google and Amazon, that their in-house data centers 
would want to more precisely and deterministically handle leap seconds. But 
note all three companies have decided to jump or smear time instead of creating 
a true leap second.
As I understand it its not that they are interested in precise or 
accurate time - they are interested in smoothing over the Leap Second 
to avoid problems potentially caused by the Leap Second jump in the many 
OSs running in the data centers. Its a work around for the timekeeping 
flaws and bugs in the system's computers and applications that may fail 
on Leap Seconds in one way or another.


-Brooks


/tvb

[1] https://redmondmag.com/articles/2015/04/08/windows-xp-usage.aspx


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Google, Amazon, now Microsoft

[Brooks Harris]

On 2015-06-01 12:37 PM, Tom Van Baak wrote:

Tom Van Baak said:

On a positive note, this means one could actually experience more than one
Windows non-leap-second on June 30. Maybe this year I should try to
celebrate the leap second twice, in Mountain and in Pacific time. Time to
pull out the road map.

Why stop with Mountain and Pacific?  There are many more time zones to try.

If you don't capture the event you want, just change the time zone and try
again.  You have an hour to tweak things and get setup to try again.

Hi Hal,

Oh, I wasn't thinking of cheating and adjusting timezones with a mouse click. 
For maximum photo effect, I was planning to drive my mobile (car) time lab 
across two time zones the night of June 30 and catch two Azure leap seconds. 
Timezones are too wide to hit three in under 2 hours.
You'll need a faster car. Or a plane. Maybe we could get the guys on the 
space station to try it?




/tvb
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] authoritative tz project info

[Brooks Harris]

On 2015-06-01 03:25 PM, Steve Allen wrote:

On Mon 2015-06-01T12:05:08 -0700, Tom Van Baak hath writ:

Can you send me a definitive URL with global TZ rules so I can
grep|sort|uniq to get a feel for when DST transitions occurs?  I guess
I thought it always was 2 am local (which implies jumps from 02h-03h
and 02h-01h).

I believe several Arab countries change at midnight.
This is the one-stop shopping authoritative data

https://www.iana.org/time-zones

except that the IANA content is repackaged by various vendors inside
of various toolkits for various platforms, so your system may not
follow those rules.


Also, possibly related, do you know of any place where DST is +/- 2
hours instead of +/- 1 hour?  I ask because the still-in-development
PE (phase encoded) WWVB format appears to allow for such a (non US
legal) transition.  I can't quite tell if it's a bug or typo or spec.

These are good questions for the tz mail list because the denizens
there have memory of many of the crazy things that local officials
have declared during the history of the tz project.


And there's the Windows timezones. They don't match tz database 

The top of Windows registry hive holding the timezone information for 
each of the supported timezones. Note this data is dynamically updated 
with a Windows Update. There's no authoritative information I've found 
on how Microsoft goes about accumulating and managing this information.


HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones

The Windows registry key holding the currently selected timezone information

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation

-Brooks


--
Steve Allen s...@ucolick.org   WGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165   Lat  +36.99855
1156 High StreetVoice: +1 831 459 3046  Lng -122.06015
Santa Cruz, CA 95064http://www.ucolick.org/~sla/Hgt +250 m
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Google, Amazon, now Microsoft

[Brooks Harris]

Hi Tom and Rob,

On 2015-05-30 06:05 PM, Tom Van Baak wrote:

Perhaps one should point out that local midnight is pretty much the worst
possible time for astronomers to accommodate such a change?

Hi Rob,

Oh, you're such an old earth+photon guy. Ask any space probe, neutrino, or 
gravitational astronomer if they share your sleep problem. ;-)

I understand that's why JD rolls over at noon instead of midnight. But, for the 
other 7 billion people on the planet, it's nice that the calendar, and local 
legal time, and even MJD rolls over at midnight instead of noon.

I can totally sympathize with Microsoft's fix for leap seconds.
I can't find any authoritative announcement or statement to this effect 
from Microsoft, and most references seem to go back round to this The 
Register article. Where does this information come from?

Laugh if you want. But out of history, ignorance, compatibility, or dogma their 
first fix was never to accept or display a 61st second in the first place. 
Windows is more POSIX than POSIX, when you think about it.
Well, the lack of the 61st second (and 58 rollover) in most computer 
timescale implementations is at the root of the Leap Seconds problems. 
Windows shares that flaw - the Leap Second count itself goes missing.

This recent fix
I got to thinking - what does Windows itself do, what has it always 
done, in this respect? Its sort of an obvious question that never 
occurred to me. I think maybe it's always done what this article says 
Azure its now going to do (or has been doing all along?).


I was experimenting a bit with the Windows time API itself to see if I 
could determine this. My investigation is a bit inconclusive at the 
moment, but I can't see where there is any difference in the way it 
counts on local timescales, in other words all local timescales are 
identical including, it seems, that a Leap Second occurs just before 
midnight. I'm not sure yet.


Finding authoritative information about Windows time mechanisms is 
difficult. I've never found a detailed enough explanation to answer my 
questions satisfactorily. Parts are obvious enough - it follows NTP, and 
it has dynamic (with a Windows update) timezone information in its 
registry (which conveniently does not match tz database). I don't 
believe it retains the Leap Second history anywhere.


There is this recent article that shows just how complicated the 
questions actually are.. Oh, and note, Window has had a smear 
mechanism in it since at least 2000 Server. Its not clear from this if 
that smear would, or is intended to, paper over a Leap Second from NTP.


How the Windows Time Service Works
https://technet.microsoft.com/en-us/library/cc773013(v=ws.10).aspx

Also note -
GetSystemTimeAdjustment function
https://msdn.microsoft.com/en-us/library/windows/desktop/ms724394

SetSystemTimeAdjustment function
https://msdn.microsoft.com/en-us/library/windows/desktop/ms724943


avoids another side effect of leap seconds -- where it affects the Far East 
much more than Europe or even the US. Now every timezone gets the same 
treatment as London.

Its much more symmetrical and easier to implement that way.

Yes, I know it's against UTC rules.
Can anyone point me to a standard or specification that *explicitly and 
clearly* states that a Leap Second is to be accounted for, or 
instantiated, in the local-time count at any other time-point than the 
last second of the day? I've seen it stated, but not as an official, 
international, agreement or specification. It seems to be only common 
use, and if Windows isn't doing it then its not very common.


In glibc we see that __tzfile_compute() (amongst the many functions 
related to gmtime() ) executes rather complex code that appears to apply 
the Leap Second differently on different timezones.


I'm quite familiar with the details and source of the implementation of 
the POSIX time mechanisms as supplied by the Microsoft MSVC c/c++ 
environment. It doesn't have mechanisms to treat the Leap Second 
differently on different timezone like glibc seems to.


I've studied the POSIX spec in regard to time carefully. I don't see 
where it calls for treating different timezone Leap Second updates 
differently. Maybe I'm missing it? How is it that glibc seems to have 
taken up that convention? Why does Microsoft's implementation lack it? 
Can anyone explain this?




I'm also looking forward to reading the unpublished research papers that 
discuss the negative side of having 24+ different leap second events around the 
globe. What a mess.
Yes, it really doesn't make sense to have a discontinuity in the count 
in the middle of the day. Of course the whole of timekeeping barely 
makes sense. :-)


-Brooks

On a positive note, this means one could actually experience more than one 
Windows non-leap-second on June 30. Maybe this year I should try to celebrate 
the leap second twice, in Mountain and in Pacific time. Time to pull out the 
road map.

/tvb

Re: [LEAPSECS] Google, Amazon, now Microsoft

[Brooks Harris]

On 2015-05-31 03:57 AM, Brooks Harris wrote:

On 2015-05-31 02:41 AM, Poul-Henning Kamp wrote:


In message 556a6bd2.50...@edlmax.com, Brooks Harris writes:


I can't find any authoritative announcement or statement to this effect

from Microsoft, [...]

Please note that this is *only* about Microsofts Azure cloud service,

Yes, that's what that articles says, but what does Microsoft say?

(which according to rumours are mostly used to run Exchange servers).

Indeed, rumors. What does Microsoft say?


This is *NOT* how your private/work Windows machine will behave,
Well, that's my question. Sure, a single machine catches up when it 
synchronizes to NTP. But what is Windows doing with the Leap Second 
count in each timezone?


The article I referenced earlier said Applies To: various Windows 
Server versions - it doesn't mention Vista, Win 7, Win 8, etc.


How the Windows Time Service Works
https://technet.microsoft.com/en-us/library/cc773013(v=ws.10).aspx

So, the timing mechanisms are complex, depending on Windows version, 
hardware, and administration choices.


My question is, if Azure is doing this, what is Windows itself doing?


for that no new information is available and the most recent
guidance was that somewhere between a second and an hour later
the clock will step a second.

most recent guidance from whom?

As I understand it, the clock would step a second when it syncs with 
NTP, but note there are apparently different capability NTP clients in 
various Windows versions. But what happens in different timezones?


-Brooks


This says it applies to Server versions and Win 7, 8, etc.

How the Windows Time service treats a leap second Print Print Email Email
https://support.microsoft.com/en-us/kb/909614

It doesn't mention how it may apply to local time.

-Brooks










___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Google, Amazon, now Microsoft

[Brooks Harris]

On 2015-05-31 02:41 AM, Poul-Henning Kamp wrote:


In message 556a6bd2.50...@edlmax.com, Brooks Harris writes:


I can't find any authoritative announcement or statement to this effect

from Microsoft, [...]

Please note that this is *only* about Microsofts Azure cloud service,

Yes, that's what that articles says, but what does Microsoft say?

(which according to rumours are mostly used to run Exchange servers).

Indeed, rumors. What does Microsoft say?


This is *NOT* how your private/work Windows machine will behave,
Well, that's my question. Sure, a single machine catches up when it 
synchronizes to NTP. But what is Windows doing with the Leap Second 
count in each timezone?


The article I referenced earlier said Applies To: various Windows 
Server versions - it doesn't mention Vista, Win 7, Win 8, etc.


How the Windows Time Service Works
https://technet.microsoft.com/en-us/library/cc773013(v=ws.10).aspx

So, the timing mechanisms are complex, depending on Windows version, 
hardware, and administration choices.


My question is, if Azure is doing this, what is Windows itself doing?


for that no new information is available and the most recent
guidance was that somewhere between a second and an hour later
the clock will step a second.

most recent guidance from whom?

As I understand it, the clock would step a second when it syncs with 
NTP, but note there are apparently different capability NTP clients in 
various Windows versions. But what happens in different timezones?


-Brooks






___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Bong

[Brooks Harris]

I synced my Windows 7 using my own SNTP implementation about two minutes 
before 8PM New York (Eastern Daylight Time). The SNTP data reported the 
Windows within 0.0004 of the NTP - pretty good! I watched the Windows 
clock carefully. It counted up 8:00:56, 57, 58, 59 as expected with a 
nice one second tick, then rolled to 8:00:00. Then, after the Leap 
Second, the SNTP reports Windows v.s. NTP -0.900 secs. Then I 
re-synced the Windows - now -0.018. So, the Windows did NOT count 
the Leap Second on its own until after the NTP update, as expected.


Meantime, on the desk I had an Android smart phone (Samsung), set to 
automatic from network. It rolled to 8:00 at the nearly the same time 
as near as I could judge. Meantime the Time Warner cable settop box 
clock also rolled to 8:00 at the same time as near as I could judge. 
After the Leap Second and updating the Windows, the Windows and the 
Android roll on the minute together, near as I can judge - seems the 
CELL network applied the Leap Second. The cable box seems to be updating 
one second late so far (twenty minutes after 8:00PM).


Not very scientific, but the Windows and personal clocks seemed to have 
worked more or less without the galaxy collapsing..


-Brooks

On 2015-06-30 07:03 PM, Tony Finch wrote:

Just heard the midnight (+0100) chimes from Big Ben on Radio 4 FM. The
bong was one second late, so I gather they already applied the leap
second. Or my DAB radio also buffers horribly even in FM mode...

Tony.


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] EBML: yet another date format?

[Brooks Harris]

On 2015-06-29 02:19 AM, Hal Murray wrote:

Looks to me they mean 128 bits?

How did you get that?

Er, by not thinking very clearly :-\



supported by a signed 8-octet integer in nanoseconds centered on

8*8 is 64.  I didn't see anything about using two of them.

Right. My obvious error.


POSIX uses 32 bits of seconds and 32 bits of nanoseconds.  That will wrap in
2038.  Using all nanoseconds gets a few more bits so the overall range will
be a bit bigger.  (Whether it's enough bigger is another matter.)

You can get to approximately 3000 years of seconds and retain the Leap 
Second count in 32 bits with -


21 bits unsigned - Days (86400 second days) (2^21 = 2097152 max / 
365.2425 = 5741.8 years max)
11 bits unsigned - Leap Seconds (2^11 = 2048 max * 1.65 Years per Leap 
Second = 3379.2 years max approx)


-Brooks

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] EBML: yet another date format?

[Brooks Harris]

On 2015-06-28 07:31 AM, Hal Murray wrote:

Can somebody do the math to figure out what range of dates would be
supported by a signed 8-octet integer in nanoseconds centered on
2001-01-01?

64 bits of nanoseconds covers 584 years
divide by 2 if you want signed (63 bits)


Looks to me they mean 128 bits?

By the way, 1588/PTP timestamp is 48bit seconds and 32bit nanoseconds, 
for approx 8915742 years


-Brooks
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] a new type of negative leap second

[Brooks Harris]

Problem solved!

On 2015-06-29 01:47 PM, Tom Van Baak wrote:

The folks at http://www.timeanddate.com/time/leapseconds.html have a leap 
second animation on the top right side of the page. I'm not sure how it 
displays for you, but attached are some screen shots on my end. Cute.

/tvb


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

[LEAPSECS] 1001 ways to beat a Leap Second

[Brooks Harris]

ASX Management of the International Leap Second
http://www.sfe.com.au/content/notices/2015/0291.15.03.pdf
-Brooks
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] What happened in the late 1990s to slow the rate of leap seconds?

[Brooks Harris]

Hi Steve,

I just wanted to compliment you on the huge about of work in these 
pages. Its a fantastic collection of facts and your explanations and 
commentary are extremely helpful. Well done and thank you.


-Brooks

On 2015-11-08 10:15 PM, Steve Allen wrote:

On Sun 2015-11-08T18:51:37 -0800, Hal Murray hath writ:

Was there a geological incident that explains things?

The crust of the earth has accelerated its rate of rotation during
most of the past 100 years.  The slowest rotation ever was around
1912, and since then it has been rotating faster.  By happenstance,
the rate of rotation of the crust was at a local minimum in 1972 at
the inception of leap seconds, and since then it accelerated again.


There is another warp in the graph in the late 1980s.  Things slowed down for
several year, but not as dramatically as the early 2000s.

Don't look at the graph of Delta T, that's effectively the integral of
the rate of rotation and its smoothness hides what the slope is
telling you.  Look at the graph of Length of Day.  That
integral/derivative pair are the first two graphs at
http://www.ucolick.org/~sla/leapsecs/amsci.html

For a historic view of the LOD going back 2000 years look at the plots on
http://www.ucolick.org/~sla/leapsecs/dutc.html

--
Steve Allen    WGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165   Lat  +36.99855
1156 High StreetVoice: +1 831 459 3046  Lng -122.06015
Santa Cruz, CA 95064http://www.ucolick.org/~sla/Hgt +250 m
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] dismaying news

[Brooks Harris]

LEAPSECS is back in business!

-Brooks

On 2015-11-18 12:25 AM, Steve Allen wrote:

Last Thursday the chair of WRC-15 Special Working Group 5A3 submitted
Temporary Document [68]
Proposals relating to agenda item 1.14
http://www.itu.int/md/R15-WRC15-151102-TD-0068/en
No further meetings of SWG 5A3 are on the calendar.

The contents of that will not be available until after it is
considered by a plenary session, but Saturday the CEPT ECC published a
MSWord document of news from the second week of WRC-15 at
http://www.cept.org/ecc/groups/ecc/cpg/page/news-from-cept-at-wrc-15,-second-week

The dismaying news in that document says there will be no decision
from WRC-15.  That means the earliest decision is at WRC-19, so there
will be leap seconds in the radio broadcast time scale at least until
2023.  The news item reads

 The sub working group (SWG 5A3) has finished its work and has
 developed a draft new WRC Resolution (as part of way forward)
 which will be discussed at WG5A meeting.

 The draft Resolution sets out the framework for further work in
 collaboration with relevant bodies (i.e.  BIPM/CIPM/CGPM etc) as
 ITU is not a proper body to decide the definition of UTC, and will
 report back in 2023 and meanwhile the ITU-R Recommendation TF
 460-6 (with leap seconds) will continue to apply until 2023.

 The draft resolution was agreed in the sub working group however
 the group could not reach an agreement on proposals to modify the
 article 1.14 of the Radio Regulations (RR) and both options now
 will be will be discussed at the next WG5A level.

 Next step: Further discussions at the WG5A level.

By 2023 the process of reconsidering leap seconds will have gone on
for more than two decades.  I suspect that many technical applications
will find they have enough agency to choose a better time scale in the
absence of an international recommendation.

--
Steve Allen    WGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165   Lat  +36.99855
1156 High StreetVoice: +1 831 459 3046  Lng -122.06015
Santa Cruz, CA 95064http://www.ucolick.org/~sla/Hgt +250 m
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] countdown to WRC-15

[Brooks Harris]

Thanks Steve, I was wondering what was going on (but lazily didn't go 
hunting).


Did the question change? It seems like the current statement is more 
elaborate, if seemingly somewhat tangled, from earlier versions?


...LEAPSECS/ITU-R/R15-WRC15PREPWORK-C-0008!!PDF-E.pdf

WRC-15 agenda item 1.14

Method A − Remove the leap second insertion or
deletion from the definition of UTC in order to
make it become a continuous time-scale and
either (A1) retain the name UTC or (A2) adopt a
new name.

Method B − Keep the current definition of UTC,
disseminate the UTC time-scale and also
disseminate a continuous time-scale (TAI) on an
equal basis.

Method C − Keep the current definition of UTC
and enable the recovery of the International
Atomic Time (TAI) (C1) or disseminate another
continuous system timescale (C2).

Method D − No change

Method (C1) seems like the choice to me, if by this they mean electronic 
dissemination of the Leap Seconds table in some useable form(s), the 
obvious missing link since 1972.


-Brooks


On 2015-08-29 02:32 PM, Steve Allen wrote:

Regional meetings continue about the fate of the leap second as
various bodies consider their position on WRC-15 Agenda Item 1.14.
http://www.itu.int/en/ITU-R/conferences/wrc/2015/Pages/reg-prep.aspx
shows that the Arab group just finished, and the European and Russian
meetings are still pending.

Next week is one more meeting of all the regional groups in Geneva
http://www.itu.int/en/ITU-R/conferences/wrc/2015/irwsp/2015/Pages/program.aspx
where item 1.14 will be covered on Thursday.

There are 6 presentations of the preparations in powerpoint documents
which are currently available there.  In particular the one on
http://www.itu.int/md/R15-WRC15PREPWORK-C-0008/en
has a chart on page 13 which shows the currently known positions of
the regional groups.  There is no consensus.

--
Steve Allen s...@ucolick.org   WGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165   Lat  +36.99855
1156 High StreetVoice: +1 831 459 3046  Lng -122.06015
Santa Cruz, CA 95064http://www.ucolick.org/~sla/Hgt +250 m
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap Seconds schedule prior to 1972

[Brooks Harris]

On 2016-04-25 12:54 AM, John Sauter wrote:

On Sun, 2016-04-24 at 20:33 -0400, Brooks Harris wrote:

Hi John,

I like the idea in general, even if its a solution in search of a
problem. I think many fields would find it useful if it found
agreement and acceptance.

Consider this:

For your "specification" I'd suggest you define the data type
generically so it can be implemented, represented, and transported by
various platforms and technologies - c/c++, Java, .NET, XML, REST,
SQL, etc, etc.

There are two critical data values: the "date" value and the TAI-UTC
value. Some *comments* in YMDhms form is probably be helpful (what
does date -123456 mean?), but the "date" variable value takes
precedence.

Define day zero as the first day of the integral UTC era - 1972-01-01
00:00:10 (TAI) = 1972-01-01T00:00:00 (UTC) is the calibration point
at which the relationship between atomic time and observed mean solar
time was made to converge on exactly 10 integral seconds as
determined by the development process of UTC.

Use negative 86400 second days as the "date" variable. Thus the last
day of your timescale is -1, which is also the last day of the
"rubber band UTC era" .

With that you've created a timescale of your own with no confusion or
controversy with Julian date, MJD, or NTP seconds and with an
unambiguous relation to UTC. A statement of how each of these are
aligned to your proleptic timescale might be useful or necessary but
your timescale is not dependent on the definitions or interpretation
of these other timescales.

The range is as high as you want - its probably not necessary to
point out a signed 64-bit day number value is a very large number of
days, something like -25,252,216,391,115,000 years, which should
cover it. I'll leave it to your research to decide how many Leap
Seconds that might require.  :-)

I'd also point out a data type using a 21-bit day number counter and
an 11-bit TAI-UTC value variable can support a range of approximately
3000 years in 4 bytes, 32-bits. This is a nice small data type
suitable for fast transfer and compact storage in binary
implementations.

-Brooks


Hi Brooks,

I agree that the data file should have comments which express the dates
as year-month-day.  However, I don't understand the benefit of coding
the date as negative 86,400-second days.  There is already a well-
understood and widely used coding for days: the Julian Day Number.

Hi John,

"understood and widely used ", yes. Standardized by an international 
standards organization, I'm not sure. Anyone know of one? There's a lot 
of things in timekeeping that are done on a "common practice" or "de 
facto standard" basis. In some cases these are not as commonly 
understood as one might wish.

  Doing something non-standard just to create a unique time scale
doesn't seem like a good enough reason.
It can avoid any ambiguity of interpretation if its clearly defined 
especially its alignment to 1972-01-01

00:00:10 (TAI) = 1972-01-01T00:00:00 (UTC).

Julian Day has an epoch of "12 noon 1 JAN -4712 (4713 BC)". Beyond that 
you've got to go to a "proleptic Julian Date" which is not exactly 
"standard". A negative 86400 second day number extends to the 
arbitrarily distant past depending on how many bits you decide to carry.


Julian Day may be OK. But somebody might ask when, exactly, did the 
Chicxulub meteor impact? I know that's beyond your scope but your 
timescale extended further as need arose.




I am happy for programs which read the data file to compress it to suit
their needs, but TAI-UTC won't fit in 11 bits if you want to go back to
the year -1000, which has a DTAI over 25,000.


Right. Depends on how far back you want to go. 11-bits TAI-UTC gives you 
2048 Leap Seconds, so, by your table 1, back to year 1000 or there 
abouts. That would be good enough for a lot of historical events. Who 
uses it for what would drive the implementation choices. 32-bits is very 
lightweight. Its just an observation - your target range is bigger.


-Brooks


 John Sauter (john_sau...@systemeyescomputerstore.com)


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap Seconds schedule prior to 1972

[Brooks Harris]

On 2016-04-25 11:11 AM, John Sauter wrote:

On Mon, 2016-04-25 at 09:40 -0400, Brooks Harris wrote:

  Hi John,
"understood and widely used ", yes. Standardized by an international
standards organization, I'm not sure. Anyone know of one? There's a
lot of things in timekeeping that are done on a "common practice" or
"de facto standard" basis. In some cases these are not as commonly
understood as one might wish.

I also don't know of an ISO standard for the Julian Day Number, but it
has been used by astronomers for about 400 years, and everybody seems
to agree on its definition.
Yes, its well known and well established. But it drives me a little nuts 
when there's not a real standard, and timekeeping is full of such 
things. Gregorian calendar is well defined in ISO 8601 for example, and 
that is something you can hang your hat on. UTC similarly, but the 
specifications are scattered throughout BIPM, IERS, and ITU-R so its not 
so easy to understand. It holds water in the end, but its pretty fragmented.



  Doing something non-standard just to create a unique time scale
doesn't seem like a good enough reason.

  It can avoid any ambiguity of interpretation if its clearly defined
especially its alignment to 1972-01-01
00:00:10 (TAI) = 1972-01-01T00:00:00 (UTC).


To be sure, but it is also possible to avoid any ambiguity of
interpretation by using a well-understood and widely-used method for
specifying days.
Sure. But a negative 86400 day number is simpler to explain, understand, 
and implement - no conversion required until you need to align it to 
something else - Julian, MJD, POSIX, PTP, GPS, etc. Just a thought.



Julian Day has an epoch of "12 noon 1 JAN -4712 (4713 BC)". Beyond
that you've got to go to a "proleptic Julian Date" which is not
exactly "standard". A negative 86400 second day number extends to the
arbitrarily distant past depending on how many bits you decide to
carry.

Julian Day may be OK. But somebody might ask when, exactly, did the
Chicxulub meteor impact? I know that's beyond your scope but your
timescale extended further as need arose.


I suspect negative Julian Day Numbers isn't "a standard" because there
is little need for them.  I myself don't have any problem with negative
Julian Day Numbers.  The meteor hit at approximately Julian Day Number
-24,105,840,000.

OK. Wow. Fun to think about :-)

Maybe someday we will know when it hit to the day, or
even the second.

A really good time scale would start with the Big Bang and count time
using a fundamental unit something like Planck time, about 10 to the
-43 seconds.
Yup. But "proleptic UTC" as you are doing it is a useful engineering 
approximation for "civil time" purposes on Earth. It gets a little dicey 
if you ask what proleptic UTC time it was when the impact that created 
the moon occurred. Were there Leap Seconds before that?


-Brooks





I am happy for programs which read the data file to compress it to
suit
their needs, but TAI-UTC won't fit in 11 bits if you want to go
back to
the year -1000, which has a DTAI over 25,000.
  
Right. Depends on how far back you want to go. 11-bits TAI-UTC gives

you 2048 Leap Seconds, so, by your table 1, back to year 1000 or
there abouts. That would be good enough for a lot of historical
events. Who uses it for what would drive the implementation choices.
32-bits is very lightweight. Its just an observation - your target
range is bigger.

-Brooks




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap Seconds schedule prior to 1972

[Brooks Harris]

On 2016-04-27 11:53 AM, John Sauter wrote:

On Wed, 2016-04-27 at 11:41 -0400, Brooks Harris wrote:

Hi,

One quick comment -

Couldn't we computer folks start to use the very sensible ISO 8601
date format? For example

EXPIRATION_DATE=2457751 # 2016 12 28

-Brooks


I used Day Month Year with the month as a three-letter abbreviation
because the leap-seconds.list file from IETF (and I think others) does
it this way.  That is also my excuse for using "#" as the comment
marker.
 John Sauter (john_sau...@systemeyescomputerstore.com)
I understand. But its always seemed to me those old formats should be 
obsolesced, that ISO 8601 presented an attractive alternative, that the 
YMDhms order made such good sense. Of course formats must remain reverse 
compatible, so they've proably had to stick with what they'd done. But 
in your case the whole timescale is new (wait, maybe its old? :-) ) so 
its an opportunity to suggest adopting a more sensible and modern lexicon.


-Brooks



PGP fingerprint = E24A D25B E5FE 4914 A603  49EC 7030 3EA1
9A0B 511E



___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap Seconds schedule prior to 1972

[Brooks Harris]

Hi,

One quick comment -

Couldn't we computer folks start to use the very sensible ISO 8601 date 
format? For example


EXPIRATION_DATE=2457751 # 2016 12 28

-Brooks

On 2016-04-27 11:14 AM, John Sauter wrote:

I have written the sample code that Hal suggested, along with its data
file.  I attach both to this e-mail message, and they are included as
embedded files with the updated paper, which is at the usual URL:

https://www.systemeyescomputerstore.com/proleptic_UTC.pdf

The data file is preliminary, going back only to just before 1700.
  That is enough to be useful, but it does not cover the whole date
range.  The data also appears in the paper as a new table in section 8:
Extraordinary Days by Julian Day Number.  Completing the data file will
add about 25,000 lines to it, which might make the paper excessively
long if it were included as a table.  Would a shorter table be
acceptable, even after the data file is completed?

Also, any other comments on the paper would be appreciated.
 John Sauter (john_sau...@systemeyescomputerstore.com)


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap Seconds schedule prior to 1972

[Brooks Harris]

On 2016-04-27 05:11 PM, John Sauter wrote:

On Wed, 2016-04-27 at 15:13 -0400, Brooks Harris wrote:
  
  I understand. But its always seemed to me those old formats should

be obsolesced, that ISO 8601 presented an attractive alternative,
that the YMDhms order made such good sense. Of course formats must
remain reverse compatible, so they've proably had to stick with what
they'd done. But in your case the whole timescale is new (wait, maybe
its old? :-) ) so its an opportunity to suggest adopting a more
sensible and modern lexicon.
-Brooks


Since the Gregorian dates appear only as comments they could be changed
easily.  Perhaps we should show both forms.  What do other people on
this list think should be done?
 John Sauter (john_sau...@systemeyescomputerstore.com)
Not two! That just begs more confusion. My complaint that 8601 style is 
not more widely adopted should not slow down your proposal - its a minor 
point of style.

-B



___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Hawking / PBS TV show about Time

[Brooks Harris]

Oh that is just too cool! Well done!
-Brooks

On 2016-05-18 01:09 PM, Tom Van Baak wrote:

Slightly off-topic, but this may be of interest to some of you who aren't also 
on the time-nuts list.

Tonight, Wednesday evening (May 18) look for a TV show on National Geographic or PBS 
called "Genius by Stephen Hawking". Episode 1: Can We Time Travel?

I mention this because I may be in this episode, or at least my atomic clocks 
and car are in it. Last year a UK-based production company contacted me and I 
offered to help them by repeating the relativity experiment I did years ago on 
Mt Rainier.

This time we chose the summit of 9100 foot Mt Lemmon (near Tucson, AZ) and in 
January I drove down with all the clocks and equipment. The six-part Hawking 
series covers a wide variety of science topics and this atomic clock bit is 
just one small part, of one episode, of one series. Still, it was quite 
adventure.

PBS info here:
http://www.pbs.org/genius-by-stephen-hawking/episodes/episode-1/

Some background on the experiment:
http://LeapSecond.com/great2016a/

And more photos and technical information:
http://LeapSecond.com/great2016a/photos.htm

Thanks,
/tvb
www.LeapSecond.com

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

[Brooks Harris]

Hi Warner,

On 2016-07-20 11:34 AM, Warner Losh wrote:

On Wed, Jul 20, 2016 at 8:23 AM, Brooks Harris <bro...@edlmax.com> wrote:

Hi Tom,

A couple questions and thoughts concerning standards and nomenclature -

On 2016-07-20 01:08 AM, Tom Van Baak wrote:

Hi Mark,

Three comments:

1)
I recall this is a known problem in the Z3801A status reporting, and
possibly other GPS receivers of that era as well. It stems indirectly from a
change years ago in how far in advance IERS and DoD were able to update the
leap second info into the GPS constellation. Nowadays it's common to get 6
months notice; it wasn't always that much.

TF.460-6 says:
"2.3The IERS should decide upon and announce the introduction of a
leap-second, such an announcement to be made at least eight weeks in
advance."

I seem to recall finding a really old version of TF.460 that didn't have the
minimum time.
Could be. I've not researched when "at least eight weeks" came into it. 
But maybe no matter - what we need is clear specifications about what 
will happen when and exactly what it means



Is there a statement in some document from BIPM or IERS that states their
current announcement policy? How, when, and why is it different from 460? I
mean, more lead time is a good thing, but what, exactly, is an implementer
to expect and what standard would would they look to learn and confirm that?

6 months (about 25 weeks) is at least 8 weeks, so it is in conformance with
TF 460-6. However, that's a good question. Judging on what has happened with
these announcements, one can count on no more than 6 months of lead time,
though IERS is at liberty to make an announcement more than 6 months in
advance.
Right. The lead time for making the announcement is not the same as an 
"expiration" or "promise". And the lack of specificity about what they 
may or may not do does not help consistency of implementations.


I've not come across documentation of this practice, however. At least nothing
more than a similar statement to mine based on observed behavior.
Thanks for the confirmation I haven't missed something by somebody 
somewhere.





We typically reserve the word leap second "pending" for the month in which
the leap second will actually occur.


Is there a statement in some document that states this use of the word
"pending"? In my research, centered on published standards and conventions,
I've not encountered the word "pending" used this way, exactly. Where does
it come from and why?

The "pending" bit comes from a long line of time gear that has a pending
leap second light or other indication that a leap second is coming. It's the
preferred jargon of the trade as well. I've seen it used in a variety
of contexts,
ranging from the IRIG context where, through an extension, you have about
an hour's notice of the leap second (so the pending bit is set) to GPS receivers
that indicate there's a pending leap second as soon as it gets pushed out to the
almanac (since it's not a bit that's set, but states when the leap will happen).

But mostly, I've seen many filters that limit the propagation of the leap second
information to be a much shorter time. The only "safe" time to convent the one
bit of information that 'we are having a leap second' is in the calendar month
prior to the leap second. Leap seconds happen only at the end of any month,
so that's the only way you can be sure. Common practice since 1972 has been
to only schedule them in the primary slots of June and December.
OK, I see. "preferred jargon", but no official or due-process 
definition. So this leaves no *clear* distinction between "pending" and 
"announce".






So just because we now know a leap second will occur in December we don't
say, here in July, that a leap second is pending. Instead we say a leap
second has been scheduled, or has been announced, or something like that.

"something like that" isn't very precise. Seems to me there should be a
statement in some official document that clarifies what words are to be used
and what they mean.

I'd love to see that. However, much of the time-keeping practice isn't written
down in official documents. It's enough of a niche thing that people in the
profession are just expected to know the terms and conventions. They act
as a shibboleth to other practitioners.

Yes, it sure is.



Many statements on this list and elsewhere casually say "at midnight". This
is very misleading to naive readers. I've been in discussions concerning
timekeeping protocols where there was a misunderstanding that "at midnight"
meant the first second of the day and the protocol would have introduced the
Leap Second incorrectly. It eventually got sorted out, but was an expensive
detour.

Ah, many, many systems I fixed FreeBSD to repeat the last second of the
prior day (as the least aweful of the choic

Re: [LEAPSECS] [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

[Brooks Harris]

Hi Tom,

A couple questions and thoughts concerning standards and nomenclature -

On 2016-07-20 01:08 AM, Tom Van Baak wrote:

Hi Mark,

Three comments:

1)
I recall this is a known problem in the Z3801A status reporting, and possibly 
other GPS receivers of that era as well. It stems indirectly from a change 
years ago in how far in advance IERS and DoD were able to update the leap 
second info into the GPS constellation. Nowadays it's common to get 6 months 
notice; it wasn't always that much.

TF.460-6 says:
"2.3The IERS should decide upon and announce the introduction of a 
leap-second, such an announcement to be made at least eight weeks in 
advance."


Is there a statement in some document from BIPM or IERS that states 
their current announcement policy? How, when, and why is it different 
from 460? I mean, more lead time is a good thing, but what, exactly, is 
an implementer to expect and what standard would would they look to 
learn and confirm that?




We typically reserve the word leap second "pending" for the month in which the 
leap second will actually occur.


Is there a statement in some document that states this use of the word 
"pending"? In my research, centered on published standards and 
conventions, I've not encountered the word "pending" used this way, 
exactly. Where does it come from and why?



So just because we now know a leap second will occur in December we don't say, 
here in July, that a leap second is pending. Instead we say a leap second has 
been scheduled, or has been announced, or something like that.
"something like that" isn't very precise. Seems to me there should be a 
statement in some official document that clarifies what words are to be 
used and what they mean.


There's more info on all of this back in the time-nuts and LEAPSECS archives if 
you want to dig deeper.

2)
Note this is not a problem for LF time services like WWVB which reserve two 
bits; one that tells you if a leap second is pending (this month) and one that 
tells you if it's an insert (positive) or delete (negative) leap second.
I think *omit* is a better term than "delete" for a negative Leap 
Second. -MM-DDT23:59:59Z isn't "deleted", its omitted from the 
YMDhms labeling sequence.


[By the way, and there's no changing this, of course, but "Leap Second" 
is itself a misnomer; only positive Leap Seconds produce a "leap" in the 
YMDhms count. In the video business, in SMPTE timecode, there is a 
compensating counting scheme (a "count mode") named "Drop-frame" where 
some hh:mm:ss:frame labels are "dropped", or omitted. This is analogous 
to a negative Leap Second. So a negative Leap Second could be called a 
"Drop Second". I'm not suggesting that, but only to illustrate the point 
of using the word "omit".]

For WWVB it's either this month or it's not at all.

It's a minor problem for NTP because it AFAIK it can only tell you one day in 
advance if a leap second is going to happen at midnight.
Many statements on this list and elsewhere casually say "at midnight". 
This is very misleading to naive readers. I've been in discussions 
concerning timekeeping protocols where there was a misunderstanding that 
"at midnight" meant the first second of the day and the protocol would 
have introduced the Leap Second incorrectly. It eventually got sorted 
out, but was an expensive detour.


With Leap Seconds now with us for at least a decade one would hope the 
BIPM, IERS, and ITU might find a way to consolidate the UTC 
specifications with a common and well defined nomenclature.


-Brooks



It's a mess for NMEA; there are no standard messages that give leap second 
announcements. The time just jumps or stutters, whether you or your boating 
equipment expects it or not.

It's not a problem for GPS because internally a leap second is not indicated by 
flag bits at all. Instead they use two fields for the pre- and the post- 
UTC-GPS offset, as well as the GPS week/day number when the change takes/took 
effect. So there's the potential for years of advance notice of a leap second.

So GPS is robust, WWVB is fine, avoid NMEA, and NTP is kind of fragile with 
respect to leap second announcements. I assume Galileo does it right. GLONASS, 
on the other hand, is known to have problems every time there's a leap second.

Just to be clear, this Z3801 anomaly is not a GPS problem. IIRC, it's not even 
an Oncore VP GPS board problem either; instead the hp CPU firmware is overly 
enthusiastic about how to transform a GPS leap second *announcement* into a 
Z3801A leap second *pending*. But it all works out fine in the end; this has 
happened on other recent leap second announcements, so not to worry.

3)
Some things to know, as a writer of software that involves users, GPS 
receivers, and leap seconds...

If you're writing embedded software try to never hardcode any leap second 
tables.

In general there's a common belief that a leap second can only occur at the end 
of June or December. This is false. Don't 

Re: [LEAPSECS] [time-nuts] Leap second to be introduced at midnight UTC December 31 this year

[Brooks Harris]

On 2016-07-20 11:27 AM, Martin Burnicki wrote:

Brooks Harris wrote:

On 2016-07-20 01:08 AM, Tom Van Baak wrote:

I recall this is a known problem in the Z3801A status reporting, and
possibly other GPS receivers of that era as well. It stems indirectly
from a change years ago in how far in advance IERS and DoD were able
to update the leap second info into the GPS constellation. Nowadays
it's common to get 6 months notice; it wasn't always that much.

TF.460-6 says:
"2.3The IERS should decide upon and announce the introduction of a
leap-second, such an announcement to be made at least eight weeks in
advance."

Is there a statement in some document from BIPM or IERS that states
their current announcement policy? How, when, and why is it different
from 460? I mean, more lead time is a good thing, but what, exactly, is
an implementer to expect and what standard would would they look to
learn and confirm that?

Each bulletin C from IERS says:

"Leap seconds can be introduced in UTC at the end of the months of
December  or June, depending on the evolution of UT1-TAI. Bulletin C is
mailed every six months, either to announce a time step in UTC or to
confirm that there will be no time step at the next possible date."


Hi Martin,

Right, thanks.

We all understand Bulletin C is the single most official Leap Second 
announcement, but its not a specification. That paragraph contributes to 
the incorrect impression that "Leap seconds can be introduced in UTC at 
the end of the months of December or June" when in fact Rec 460 says 
"2.1A positive or negative leap-second should be the last second of 
a UTC month, but first preference should be given to the end of December 
and June, and second preference to the end of March and September.". 
That means it can happen at the "end of any month", as Tom points out, 
and only that "preference" be given to December, June, March, and 
September.


Exactly what "preference" means in Rec 460 is a little vague, too, but 
we get the idea that IERS makes a judicious balance between the 
precision of UT1 v.s. UTC and convenience of some "end of month". It 
might not be directly relevant to UTC implementations but it would be 
comforting to know more clearly how IERS does that. It might be 
explained in their conventions, I'm not sure. The various guidance 
documents are helpful, but not definitive. One wishes there were a 
single document with common terminology that had undergone due-process 
to yield an official specification.


Bulletin C is but one of several "products" of the IERS. Bulletin C, 
curiously, does not specify an "expiration" except as implied by the 
statement "Bulletin C is mailed every six months, either to announce a 
time step in UTC or to confirm that there will be no time step at the 
next possible date." I'm not exactly sure what that means, because, 
presumably, Leap Seconds could occur more frequently.


Meantime, https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat 
says clearly, but in comments, "#  File expires on 28 June  2017". This 
seems to be a *promise* by IERS that they won't declare another Leap 
Second until then, but its not stated anywhere that I know of that that 
is officially true. We might surmise Bulletin C's "mailed every six 
months" statement corresponds to this expiration date and that's 
generally its meaning, but it all seems just too vague to me.


Then, of course, there's the obvious missing link - a common, 
standardized, method of automatic Leap Second metadata dissemination and 
retrieval. This topic has been discussed here many times, yet no 
official standardization process involving the BIPM, IERS, and ITU seems 
to be underway. That, it seems to me, would be an important step.


None of this is in any way a criticism of BIPM or IERS. They and all 
their contributing members do a utterly fantastic job of the "heavy 
lifting" of timekeeping. But if Leap Seconds are going to work better 
more clarity in all the documents is needed. I'm just trying to 
contribute to the conversation.


-B



Martin

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] USNO press release

[Brooks Harris]

"WASHINGTON, DC -- On December 31, 2016, a "leap second" will be added 
to the world's
clocks at 23 hours, 59 minutes and 59 seconds Coordinated Universal Time 
(UTC). This
corresponds to 6:59:59 pm Eastern Standard Time, when the extra second 
will be inserted at the

U.S. Naval Observatory's Master Clock Facility in Washington, DC. "

It seems to me not exactly wrong, but misleading in several respects:

1) Its a *positive* Leap Second
2) "introduced" or "inserted" rather than "added" are better terms 
consistent with ITU-R 460.
3) The Leap Second is not, typically, "added to the worlds clocks" in 
the same way its introduced to UTC. If "world clocks" means "local time" 
the Leap Second will typically be introduced on the local timescales 
simultaneous with its occurrence on UTC.
4) "added .. at 23 hours, 59 minutes and 59 seconds" might be 
misinterpreted to mean *before*, or somehow together with, 23:59:59. 
"Inserted following" might be more clear.

5) there's no mention of what happens in the other USA time zones.

Its always a challenge to write about UTC in a way that's both clear and 
readable. Here's my go:


The International Earth Rotation and Reference Systems Service (IERS) 
has determined a positive Leap Second shall be introduced in the 
Coordinated Universal Time (UTC) timescale at the end of the day on 
2016-December-31. The positive Leap Second will be inserted immediately 
following the second labeled 23:59:59 and labeled 23:59:60. Most world 
clocks will introduce this positive Leap Second on their local 
timescales simultaneous with its occurrence in UTC. The U.S. Naval 
Observatory's Master Clock Facility in Washington, DC will insert this 
positive Leap Second to the Eastern Standard Time (UTC-05:00) timescale 
on 2016-December-31 immediately following the second labeled 06:59:59 pm 
(18:59:59) and will be labeled 06:59:60 pm (18:59:60).


-Brooks

On 2016-07-10 11:26 PM, Jonathan E. Hardis wrote:
I don't disagree with your interpretation of UTC, but there's no error 
in the announcement.  The leap second is */added/* */at /*23:59:59. 
 While the leap second itself is 23:59:60, it's during the interval 
23:59:59 when the logic is changed for what the next second should be 
labelled.


 - Jonathan


On Jul 10, 2016, at 3:39 PM, Paul Hirose > wrote:


On 2016-07-08 12:16, I wrote:

Is there a mistake in this announcement?


http://www.usno.navy.mil/USNO/tours-events/2016_Leap_Second%20Press%20Release%20-%20Final.pdf


WASHINGTON, DC -- On December 31, 2016, a "leap second" will be added to
the world's clocks at 23 hours, 59 minutes and 59 seconds Coordinated
Universal Time (UTC).


The mistake is in the first sentence. Nothing unusual happens at 
23:59:59. One second later, at 23:59:60, the leap second begins. In 
other words, UTC will do this:


23:59:59.9
23:59:60.0
23:59:60.1
...
23:59:60.9
00:00:00.0

I have informed the author of the press release.

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com 
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] USNO press release

[Brooks Harris]

Slight tweaks were suggested offline ...

The International Earth Rotation and Reference Systems Service (IERS) 
has determined that a positive Leap Second shall be introduced in the 
Coordinated Universal Time (UTC) timescale at the end of the day on 
2016-December-31. The positive Leap Second will be inserted immediately 
following the second labeled 23:59:59 and it will be labeled 23:59:60. 
Most world clocks will introduce this positive Leap Second on their 
local timescales simultaneously with its occurrence in UTC. The U.S. 
Naval Observatory's Master Clock Facility in Washington, DC will insert 
this positive Leap Second in the Eastern Standard Time (UTC-05:00) 
timescale on 2016-December-31 immediately following the second labeled 
06:59:59 pm (18:59:59) and it will be labeled 06:59:60 pm (18:59:60).


-Brooks

On 2016-07-11 09:45 AM, Brooks Harris wrote:
"WASHINGTON, DC -- On December 31, 2016, a "leap second" will be added 
to the world's
clocks at 23 hours, 59 minutes and 59 seconds Coordinated Universal 
Time (UTC). This
corresponds to 6:59:59 pm Eastern Standard Time, when the extra second 
will be inserted at the

U.S. Naval Observatory's Master Clock Facility in Washington, DC. "

It seems to me not exactly wrong, but misleading in several respects:

1) Its a *positive* Leap Second
2) "introduced" or "inserted" rather than "added" are better terms 
consistent with ITU-R 460.
3) The Leap Second is not, typically, "added to the worlds clocks" in 
the same way its introduced to UTC. If "world clocks" means "local 
time" the Leap Second will typically be introduced on the local 
timescales simultaneous with its occurrence on UTC.
4) "added .. at 23 hours, 59 minutes and 59 seconds" might be 
misinterpreted to mean *before*, or somehow together with, 23:59:59. 
"Inserted following" might be more clear.

5) there's no mention of what happens in the other USA time zones.

Its always a challenge to write about UTC in a way that's both clear 
and readable. Here's my go:


The International Earth Rotation and Reference Systems Service (IERS) 
has determined a positive Leap Second shall be introduced in the 
Coordinated Universal Time (UTC) timescale at the end of the day on 
2016-December-31. The positive Leap Second will be inserted 
immediately following the second labeled 23:59:59 and labeled 
23:59:60. Most world clocks will introduce this positive Leap Second 
on their local timescales simultaneous with its occurrence in UTC. The 
U.S. Naval Observatory's Master Clock Facility in Washington, DC will 
insert this positive Leap Second to the Eastern Standard Time 
(UTC-05:00) timescale on 2016-December-31 immediately following the 
second labeled 06:59:59 pm (18:59:59) and will be labeled 06:59:60 pm 
(18:59:60).


-Brooks

On 2016-07-10 11:26 PM, Jonathan E. Hardis wrote:
I don't disagree with your interpretation of UTC, but there's no 
error in the announcement.  The leap second is */added/* */at 
/*23:59:59.  While the leap second itself is 23:59:60, it's during 
the interval 23:59:59 when the logic is changed for what the next 
second should be labelled.


 - Jonathan


On Jul 10, 2016, at 3:39 PM, Paul Hirose <cfuhb-ac...@earthlink.net 
<mailto:cfuhb-ac...@earthlink.net>> wrote:


On 2016-07-08 12:16, I wrote:

Is there a mistake in this announcement?


http://www.usno.navy.mil/USNO/tours-events/2016_Leap_Second%20Press%20Release%20-%20Final.pdf


WASHINGTON, DC -- On December 31, 2016, a "leap second" will be 
added to

the world's clocks at 23 hours, 59 minutes and 59 seconds Coordinated
Universal Time (UTC).


The mistake is in the first sentence. Nothing unusual happens at 
23:59:59. One second later, at 23:59:60, the leap second begins. In 
other words, UTC will do this:


23:59:59.9
23:59:60.0
23:59:60.1
...
23:59:60.9
00:00:00.0

I have informed the author of the press release.

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com <mailto:LEAPSECS@leapsecond.com>
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-02-03 04:30 PM, Warner Losh wrote:

On Wed, Feb 1, 2017 at 11:14 PM, Warner Losh  wrote:

On Wed, Feb 1, 2017 at 10:37 PM, Zefram  wrote:

Warner Losh wrote:

If you are going to willfully misunderstand, then I'm done being patient.

I am not willfully misunderstanding.  I have tried to understand
what you're doing, and I've been unable to find a system that works
consistently, uses the labelling of leap seconds on which we are agreed,
and yields TAI-UTC changing at the start of a positive leap second.
Please enlighten me.  If you were to supply the couple of worked examples
that I have suggested, I believe that would shed much light on your
system.

I've already done exactly that. I'll see if I have time tomorrow to
write it up again using TeX or something that's easier to format and
explain with than ASCII text. Based on Tom's description of my method,
I think he may misunderstand it too. It's as consistent as the
calendar system we have today.

I'm doing a longer write up, but work got crazy...

But consider TAI and UTC when they were equal, for the sake of
argument. I know they never were, but if we look at what the first one
would look like:

TAI  UTC delta
23:59:58 23:59:580
23:59:59 23:59:590
00:00:00 23:59:601
(since how can it be 0 if they are different?)
00:00:01 00:00:001

So either there's some weird math that lets one subtract two numbers
that are different and get 0 as the answer, or the delta has to change
at the start.

It's understanding what the weird math is that I'm having trouble with
for people that say it is after the leap second that the delta
changes.

I guess that would be me, primarily.

(I see Stephen Scott has joined my opinion.. as I write this.)

I'm not questioning your logic or methods. I think I get it, though I 
haven't yet tried to work it through.


But it seems to me like the question is, from where and in what form are 
we obtaining the Leap Second metadata? And its here I feel like when the 
TAI-UTC (the "delta", as you say, if I'm understanding) updates (before 
or after the Leap Second) matters as interoperability issue.


If you're obtaining the data from an external source, such as loading a 
Leap Seconds table from somewhere, like Tz Database, you could arrange 
the data anyway convenient and query it anyway you want. But when 
reading a time dissemination protocol in "real-time" how is the Leap 
Seconds metadata organized and updated?


In 1588/PTP for example, 8.2.4.2 timePropertiesDS.currentUtcOffset, "... 
the value of timePropertiesDS.currentUtcOffset is the offset between TAI 
and UTC". But it does not, as far as I can tell or know, say *when* this 
value is to change, before or after the Leap Second. That's an 
interoperability issue, and its in discussions in that context I've 
reached my current opinion; you have to assume its intended to follow 
the "specs", and the spec(s) seem to say "after the Leap Second".


If its after the Leap Second then your method doesn't work directly; 
you'd need to figure it out and make an internal adjustment to the 
TAI-UTC value a second *before* its supplied to you, right? See what I mean?


-Brooks








___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-01-31 08:21 PM, Steve Summit wrote:

Wow.  This has been quite a thread.

I feel like I should apologize for my earlier contribution to it,
which presented a nice-looking, persuasive-sounding argument
which now looks an awful lot like it's... wrong.
Not at all. Its an informed contribution. And I think it's not "wrong". 
At least not yet. I think its "right", so far.  :-)

But it seems to
have temporarily taken in (at least) Tom Van Baak and Brooks
Harris,

Standby. And I'm not sure Tom and I are seeing it the same way, yet.

until we've all been set straight by the patient
explanations of Warner Losh.

Yes, thank you Warner, pleased to have your input.


My own errors were,

Standby. Not errors yet :-)

I think, partly due to confirmation bias:
I really wanted the answer to be that the TAI-UTC offset changes
at the *end* of the leap second, because it lines up with so much
else:
* it's what the standards (seem to) say
That's what I think, but, as I said, I want to be sure, and that experts 
agree.

* it lines up with all the leap second tables out there, which
   claim to list (for example) 2017-01-01T00:00:00 UTC as the
   first instant of TAI=UTC = 37 (that is, the tables do *not*
   typically list 2016-12-31T23:59:60)
Yeah, me too. I think its more straight forward, understandable, and 
thus risks fewer off-by-one mistakes when doing table lookups.

* it just makes some kind of intuitive sense that TAI-UTC should
   change at the end of the UTC day, exactly when everything else
   is ticking over, not one second before that event.

Yeah, me too.

It strikes me as stonger than "intuitive sense". YMDhms representation 
defines the second that is midnight, and that seems like a most 
important point. Seems to me TAI-UTC is a natural part of that transition.


(But for the moment these are just laments and puzzlements;
I am not putting them forth as counterarguments.)

OK.


It also seems to me that this is not merely an abstract
theoretical argument; it can have practical implications.

Yes, I agree.


If I'm defining an interface which presents UTC and TAI-UTC
(so that my client can compute TAI if needed), or which presents
TAI and UTC-TAI (so that vice versa), if my client and I don't
absolutely agree on the value of TAI-UTC during a leap second,
someone's going to get the wrong answer.

(As but one example of such an interface, under Unix/Linux the
adjtimex system call can return both UTC time and a TAI offset.
In my tests I've found that the returned TAI offset value isn't
always strictly accurate, and I've been working to fix it, but
the intent of the code behind it seemed to match mine, i.e. to
change at the end of the leap second.)
Exactly places like that where I think this counts. Whole code 
superstructures could be designed and written with the wrong underlying 
objective.


What a puzzle.

The fog of UTC :-)

-Brooks

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-01-31 04:15 AM, michael.deckers via LEAPSECS wrote:


   On 2017-01-30 21:36, Brooks Harris wrote:

 It seems to me this is where the 
UTC
specifications are scattered over many documents and no one document 
makes it

clear by itself, and this leaves room for misunderstanding.


   Actually, there is just one official document
   defining UTC (ITU-R Rec 460); plus of course
   the Bulletins C of the IERS. 
Generally I agree these are the two most relevant documents. But Rec 460 
doesn't point you to Bulletin C specifically, IERS has many other 
products, and the BIPM Annual Report on Time Activities looks official, 
and it is. Its scattered in the sense you can't find anything, or, 
rather, you find many things, and Rec 460 doesn't say "as per IERS 
Bulletin C". Only after much research might you conclude Bulletin C is 
the most official, or most important, or most punctual, of the IERS 
products. Even now I'm not completely sure of that, that there isn't 
some other document somewhere


-Brooks

Everything else
   is interpretation and not necessarily correct.
   So I do not see a problem with scattered
   documents.

   What is missing quite a bit, as far as I can see,
   is a set of commonly accepted and applied "mises en
   pratique" for the leap seconds of UTC: documents
   that provide guidance for dealing with leap seconds
   in specific areas.

   Michael Deckers.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-01-31 04:44 PM, Warner Losh wrote:

On Tue, Jan 31, 2017 at 2:20 PM, Brooks Harris <bro...@edlmax.com> wrote:

It's the only way to encode one number such that the irregular radix
math works out.

I think I'm going to need an example I can work through to fully understand
you here. When you get a chance, or can point me to something, thanks.

OK.


And treating a positive leap second 'special' that
needs an extra decrement is isomorphic to changing the delta at the
start of the second.

Ah, well the Leap Second is special, isn't it, even from the point of view
of your "irregular radix
math"? You are detecting it by whatever means and then treating it as if the
TAI-UTC value incremented and the start of the Leap Second so its convenient
to your methods, right? I mean, how its detected and treated could be seen
as an internal implementation choice.

My "IsLeapSecond" flag can also be generated internally so long as there is
adequate metadata, either a IsLeapSecond or IsLeapSecondMinute, or
IsLeapSecondDay or something. But in any case you still need the TAI-UTC
value.

The simple TAIToUTCDemoConsole program is not exactly how I do it in more
elaborate code, but, generally I aim to do everything with integer math and
logic.

I wrote the little program to illustrate the resulting values, especially
the UTC seconds value, to explain what I meant by the YMDhms(TAI) and
YMDhms(UTC) and to stimulate just this convrsaion, thanks.

I've found the IsLeapSecond flag to be very helpful metadata, especially
when a receiver of a timestamp is interpreting it. If its explicitly flagged
it saves any processing to detect it.

I'm saying that the extra "is it a leap second" bit is a complication
that's not needed for the computation. The fact that it may be useful
for other things isn't really relevant.

Let's take the TAI time 2017-01-01T00:00:36.5. Now, this is, as you
know, the leap second. To compute what value this is, we take the new
offset (37s) and subtract it, giving the following unreduced answer:

2017-01-01T00:00:(36.5-37)
2017-01-01T00:00:-0.5

which we computed simply by subtracting 37 from the seconds field.
We've not yet renormalized the notation. That's where the irregular
radix stuff comes in. So, to normalize, we need to borrow one from the
minutes column. To do that, we need to borrow one from the hours and
so on. The minute we are borrowing from has 61 seconds, so we can
rewrite this as

2016-12-31T23:59:(61-0.5)
2016-12-31T23.59:60.5

which is the correct answer. We need only know the size of the minute
we are borrowing from to make the computation.

This is the same math, btw, you'd use to find an interval entirely
inside UTC. What's the time difference between 2017-01-01T00:00:01 and
2016-12-31T23:59:58? The answer is 4. We can get this two ways. First,
we can do it the tedious way of counting:

23:59:58
23:59:59 1s
23:59:60 2s
00:00:00 3s
00:00:01 4s --> Answer

We can also do it by subtracting the two times:

  2017-01-01T00:00:01-2016-12-31T23:59:58

First step is to borrow from the previous minute, which rewrites it as

2016-12-31T23:59:(61+1)-2016-12031T23:59:58
2016-12-31T23:59:62-2016-12031T23:59:58
proceeding to the subtraction, term by term, we get 00:00:04.

In both cases, we did need to know that 23:59 had 61 seconds, but we
didn't need to have a special leap second flag associated with any of
the timestamps for the math to work out right. Knowing that it has 61
seconds sometimes is exactly the same thing as knowing that sometimes
February has 29 days some years. The only difference is that one is a
math formula for thousands of years, and the other is a table lookup.

Oh. I see what you're doing now. Thanks much.

I was imagining things a little. I've been dealing with folks who are 
trying to run and prove these algorithms with tools like MatLab, so when 
you said "radix math" I was thinking "vector math". I've also spent 
months with Excel, so then everything is floating point and this really 
complicates things with handling precision errors. Excel also doesn't do 
%mod the way you need, so I had to write plugins. Ugh. These 
environments and tools are not well suited to timekeeping the way we're 
discussing it, in my opinion, but it becomes an important issue when 
grappling with communication of the subtleties. Each participant is 
approaching it from their particular environment.


(As a side note, there is complexity and miscommunication between the 
open source world and the Microsoft world, which doesn't help matters 
much. For example, I've got a big chore ahead sometime porting Tz 
Database to MSVC/Windows. We can't win or lose these OS wars, we just 
have to cope.)


So, approaching it your way will probably work fine, I don't doubt you. 
I see it as complicated, but I guess that's a matter of familiarity.


In my career I've dealt with these (crazy) SMPTE timecode timestamps. 
The nasty thing about t

Re: [LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-01-30 04:39 PM, Tom Van Baak wrote:

2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5

What kind of arithmetic is that?

Hi Michael,

First, there's no problem with this, right?  (Thanks to Steve for catching typo)

2017-01-01T00:00:35.5 TAI = 2016-12-31T23:59:59.5 UTC
2017-01-01T00:00:36.5 TAI = 2016-12-31T23:59:60.5 UTC
2017-01-01T00:00:37.5 TAI = 2017-01-01T00:00:00.5 UTC

Now, we want to use "UTC = TAI + (UTC - TAI)" notation. So which is correct:

2017-01-01T00:00:35.5 TAI - 36 s = 2016-12-31T23:59:59.5 UTC
2017-01-01T00:00:36.5 TAI - 36 s = 2016-12-31T23:59:60.5 UTC  ??
2017-01-01T00:00:37.5 TAI - 37 s = 2017-01-01T00:00:00.5 UTC

or

2017-01-01T00:00:35.5 TAI - 36 s = 2016-12-31T23:59:59.5 UTC
2017-01-01T00:00:36.5 TAI - 37 s = 2016-12-31T23:59:60.5 UTC  ??
2017-01-01T00:00:37.5 TAI - 37 s = 2017-01-01T00:00:00.5 UTC

Neither one is particularly clear to me. Of course in real code it all works 
because you special case the leap second label discontinuity and make it work. 
In a sense you replace normal sexagesimal arithmetic with 59-gesimal or 
61-gesimal arithmetic for that one minute. But, yeah, I can see that it 
complicates prose and equations regarding UTC-TAI offsets.




I think its the first one >>
2017-01-01T00:00:36.5 TAI - 36 s = 2016-12-31T23:59:60.5 UTC  ??
2017-01-01T00:00:37.5 TAI - 37 s = 2017-01-01T00:00:00.5 UTC

The Leap Second accrues to the TAI-UTC value immediately after the Leap 
Second.


As Steve Summit said earlier (with his 2015 example)

Positive leap second:

TAI   UTC   TAI-UTC
00:00:34.023:59:59.035
00:00:34.523:59:59.535
00:00:35.023:59:60.035
00:00:35.523:59:60.535
00:00:36.000:00:00.036
00:00:36.500:00:00.536

Here, in Steve's example, I think the notation is appropriate. The 
YMDhms columns are titled "TAI" and "UTC". Too often in the literature, 
and sometimes in standards specifications, we see a "date" but no 
explanation of what timescale the YMDhms representation is referring to. 
Usually, it means UTC, which I take to mean "Gregorian calendar 
algorithm with Leap Second compensation applied". But sometimes a YMDhms 
form is used to express TAI, in which case its what I'd call "pure" 
Gregorian, that is, with no Leap Second compensation.


To extend the 2016/2017 example more completely:

Two Leap Second metadata variables are required to support positive Leap 
Seconds:

1) TAI-UTC value
2) Is Leap Second - flag marking the actual Leap Second

TAI seconds - seconds-since-TAI1958
YMDhms (TAI) - YMDhms encoding by "pure Gregorian" of seconds-since-TAI1958
TAI-UTC - TAI-UTC value (initial 10s calibration at UTC1972 plus Leap 
Seconds)

UTC seconds - (seconds-since-TAI1958 - TAI-UTC)
LS - Is Leap Second (0 or 1)
YMDhms (UTC) - YMDhms encoding of (seconds-since-TAI1958 - TAI-UTC) by 
"Leap Second compensated Gregorian"


TAI seconds YMDhms (TAI)  TAI-UTC UTC seconds  LS  YMDhms (UTC)
1861920035.0 = 2017-01-01T00:00:35.0 - 36  = 186191.0 0 = 
2016-12-31T23:59:59.0
1861920035.5 = 2017-01-01T00:00:35.5 - 36  = 186191.5 0 = 
2016-12-31T23:59:59.5
1861920036.0 = 2017-01-01T00:00:36.0 - 36  = 186192.0 1 = 
2016-12-31T23:59:60.0
1861920036.5 = 2017-01-01T00:00:36.5 - 36  = 186192.5 1 = 
2016-12-31T23:59:60.5
1861920037.0 = 2017-01-01T00:00:37.0 - 37  = 186192.0 0 = 
2017-00-00T00:00:00.0
1861920037.5 = 2017-01-01T00:00:37.5 - 37  = 186192.5 0 = 
2017-00-00T00:00:00.5
1861920038.0 = 2017-01-01T00:00:38.0 - 37  = 1861920001.0 0 = 
2017-00-00T00:00:01.0


Attached - TAIToUTCDemoConsole - a rudimentary c program using POSIX 
gmtime() (a pure, strict gmtime() with 1 second resolution) demonstrates 
one way to make the calculations. Its output:


2016-2017 Leap Second
TAI seconds  YMDhms (TAI)   TAI-UTC UTC seconds LS  YMDhms (UTC)
1861920035 = 2017-01-01 00:00:35 - 36 = 186191  0 = 2016-12-31 23:59:59
1861920036 = 2017-01-01 00:00:36 - 36 = 186192  1 = 2016-12-31 23:59:60
1861920037 = 2017-01-01 00:00:37 - 37 = 186192  0 = 2017-01-01 00:00:00
1861920038 = 2017-01-01 00:00:38 - 37 = 1861920001  0 = 2017-01-01 00:00:01

-Brooks
//TAIToUTCDemoConsole.h

#ifndef TAIToUTCDemoConsole_h_included
#define TAIToUTCDemoConsole_h_included

/**
TAI seconds to YMDhms (UTC)

Demonstrates methods for calculating YMDhms UTC from TAI seconds
using classic POSIX gmtime()
(strict time_t and gmtime() operate on integral seconds)

Two Leap Second metadata variables are required
to support positive Leap Seconds:
1) TAI-UTC value
2) Is Leap Second - flag marking the actual Leap Second

Negative Leap Seconds are not supported

Brooks Harris 2017-01-31
**/

#include 
#include 
#include  // memset



// MSVC 6.0 does not support "ll" printf() directive or long long data type.

Re: [LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-01-31 01:52 PM, Warner Losh wrote:

On Mon, Jan 30, 2017 at 2:39 PM, Tom Van Baak  wrote:

2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5

What kind of arithmetic is that?

Hi Michael,

First, there's no problem with this, right?  (Thanks to Steve for catching typo)

2017-01-01T00:00:35.5 TAI = 2016-12-31T23:59:59.5 UTC
2017-01-01T00:00:36.5 TAI = 2016-12-31T23:59:60.5 UTC
2017-01-01T00:00:37.5 TAI = 2017-01-01T00:00:00.5 UTC

Now, we want to use "UTC = TAI + (UTC - TAI)" notation. So which is correct:

2017-01-01T00:00:35.5 TAI - 36 s = 2016-12-31T23:59:59.5 UTC
2017-01-01T00:00:36.5 TAI - 36 s = 2016-12-31T23:59:60.5 UTC  ??
2017-01-01T00:00:37.5 TAI - 37 s = 2017-01-01T00:00:00.5 UTC

or

2017-01-01T00:00:35.5 TAI - 36 s = 2016-12-31T23:59:59.5 UTC
2017-01-01T00:00:36.5 TAI - 37 s = 2016-12-31T23:59:60.5 UTC  ??
2017-01-01T00:00:37.5 TAI - 37 s = 2017-01-01T00:00:00.5 UTC

Neither one is particularly clear to me. Of course in real code it all works 
because you special case the leap second label discontinuity and make it work. 
In a sense you replace normal sexagesimal arithmetic with 59-gesimal or 
61-gesimal arithmetic for that one minute. But, yeah, I can see that it 
complicates prose and equations regarding UTC-TAI offsets.

I think it has to be the second one because when you work through the
math, it works out.

The math simply doesn't work out for the former. 36-36 is 0, which you
have to somehow know means 60. That's nuts, imho. However, 36-37 is
-1. When you have an underflow, you have to borrow from the previous
minute. That minute has 61 seconds, which when added to -1 gives 60,
which is the correct answer.

Otherwise you are in special case hell where you know there's a leap
second so you add one more, which is solved nicely by just bumping the
offset at the start of the leap second.
Yes, I think I understand what you mean. Your take on it does simplify 
some aspects of the math a bit, but, as I understand it, that's not what 
the specifications say. Of course, as we've been discussing, the 
specifications leave room for interpretation.


I've been in long discussions on exactly this topic, and the conclusion 
was, as I've said, TAI-UTC increments *after* the Leap Second.


We are overlapping on email responses now...

-Brooks


Warner
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-01-31 02:32 PM, Warner Losh wrote:

On Tue, Jan 31, 2017 at 12:13 PM, Brooks Harris <bro...@edlmax.com> wrote:

On 2017-01-31 01:52 PM, Warner Losh wrote:

On Mon, Jan 30, 2017 at 2:39 PM, Tom Van Baak <t...@leapsecond.com> wrote:

2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5

 What kind of arithmetic is that?

Hi Michael,

First, there's no problem with this, right?  (Thanks to Steve for
catching typo)

2017-01-01T00:00:35.5 TAI = 2016-12-31T23:59:59.5 UTC
2017-01-01T00:00:36.5 TAI = 2016-12-31T23:59:60.5 UTC
2017-01-01T00:00:37.5 TAI = 2017-01-01T00:00:00.5 UTC

Now, we want to use "UTC = TAI + (UTC - TAI)" notation. So which is
correct:

2017-01-01T00:00:35.5 TAI - 36 s = 2016-12-31T23:59:59.5 UTC
2017-01-01T00:00:36.5 TAI - 36 s = 2016-12-31T23:59:60.5 UTC  ??
2017-01-01T00:00:37.5 TAI - 37 s = 2017-01-01T00:00:00.5 UTC

or

2017-01-01T00:00:35.5 TAI - 36 s = 2016-12-31T23:59:59.5 UTC
2017-01-01T00:00:36.5 TAI - 37 s = 2016-12-31T23:59:60.5 UTC  ??
2017-01-01T00:00:37.5 TAI - 37 s = 2017-01-01T00:00:00.5 UTC

Neither one is particularly clear to me. Of course in real code it all
works because you special case the leap second label discontinuity and make
it work. In a sense you replace normal sexagesimal arithmetic with
59-gesimal or 61-gesimal arithmetic for that one minute. But, yeah, I can
see that it complicates prose and equations regarding UTC-TAI offsets.

I think it has to be the second one because when you work through the
math, it works out.

The math simply doesn't work out for the former. 36-36 is 0, which you
have to somehow know means 60. That's nuts, imho. However, 36-37 is
-1. When you have an underflow, you have to borrow from the previous
minute. That minute has 61 seconds, which when added to -1 gives 60,
which is the correct answer.

Otherwise you are in special case hell where you know there's a leap
second so you add one more, which is solved nicely by just bumping the
offset at the start of the leap second.

Yes, I think I understand what you mean. Your take on it does simplify some
aspects of the math a bit, but, as I understand it, that's not what the
specifications say. Of course, as we've been discussing, the specifications
leave room for interpretation.

Correct. They don't even talk about an offset. They just say that a
leap second is counted positiviely 58, 59, 60, 00 and negatively 58,
00. Nothing more. And that if an event happens .3s into a leap second,
it's label is mumble:60.3, or it it happens .1s a negative leap second
it would be mumble:58.9.


I've been in long discussions on exactly this topic, and the conclusion was,
as I've said, TAI-UTC increments *after* the Leap Second.

The math doesn't work out if you do that. It's certainly not what the
standard says. Since the standard is silent on when the offset
changes, the math of the situation must be controlling. I humbly
submit that the logic that lead you the conclusion that TAI-UTC
increments after the leap second is in error. It isn't supported by
TF.460 (which is absolutely silent on the issue), and it isn't
supported by the bare math of the situation when working with the
numbers of an irregular radix in the typical way one does with dates.
True, Rec 460 is silent on it. But I think Bulletin C says the TAI-UTC 
value increments at the start of the day:


" UTC TIME STEP on the 1st of January 2017" and
"from 2017 January 1, 0h UTC, until further notice: UTC-TAI = - 37s ".

It doesn't say "the second before 2017 January 1".

-Brooks


Warner

Current TF.460: https://www.itu.int/rec/R-REC-TF.460-4-198607-S/en
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-01-31 02:19 PM, Warner Losh wrote:

On Tue, Jan 31, 2017 at 12:08 PM, Steve Allen <s...@ucolick.org> wrote:

On Tue 2017-01-31T13:58:15 -0500, Brooks Harris hath writ:

Ah, so who's right?

I prefer to think of a leap second as being truly intercalary.
It is saying to atomic clock "It's not tomorrow yet, wait a second."
It is between one calendar day of UTC and the next calendar day of UTC.
It belongs to neither of them.  The tag 2016-12-31T23:59:60 is merely
a way of indicating which two days it is between.
It is unfortunate that nobody thought this stuff through in 1969 when
the decision was made to implement the leap second, and no matter how
it is expressed, encoded, and calculated it will be a special case.

Philosophically you may be right.
It doesn't seem philosophical to me. Its obviously a special case, a 
special case of interoperablity decreed by the IERS.


Mathematically, however, I don't think that makes much sense. :60 is
an irregular radix. It's clearly added to the prior day, just like Feb
29th is part of February.

Yes.

Also, doing the long-hand math on the
irregular radix, it also makes sense to have it be part of the prior
day

It is, right? And that's what Rec 460 clearly says.

and to increment the offset at the start of the leap second.

Not necessarily.

What part of Gregorian YMDhms or DST makes any "sense"? They are 
unavoidable conventions, wacky unavoidable conventions with mixed radix 
components and deceptive algorithmic rules. UTC with Leap Seconds alters 
those conventions slightly. Why would we expect it to "make sense"?


I think Bulletin C says the TAI-UTC value increments at the start of the 
day:


" UTC TIME STEP on the 1st of January 2017" and
"from 2017 January 1, 0h UTC, until further notice: UTC-TAI = - 37s ".

It doesn't say "the second before 2017 January 1".

-Brooks




Warner
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-01-31 12:33 PM, Warner Losh wrote:

On Tue, Jan 31, 2017 at 7:54 AM, Steve Summit  wrote:

Tom Van Baak and Michael Decker wrote:

2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5

What kind of arithmetic is that?

I think it ends up being roughly the same kind of arithmetic
that tells you that the 60th day of the year is March 1.
Or maybe February 29.

Maybe he's referring to the fact that the offset is 37s, not 36s. The
offset changes AT THE START OF THE LEAP SECOND.
OK, now here's something I've been worrying about for a long time. 
Everyone on LEAPSECS, and seemingly everywhere else in the literature, 
are *sure* they know exactly what UTC with Leap Seconds is. Yet the 
specifications are unclear, as we've been discussing.


Here you are saying "The (TAI-UTC) offset changes AT THE START OF THE 
LEAP SECOND. " That is in direct conflict with my best understanding of 
it. I'd say "The (TAI-UTC) offset changes immediately AFTER the Leap 
Second, at the midnight roll-over to the first second of the next 
month." (See other email with my explanation and demonstration code).


So, this is obviously a huge interoperablity issue. It has ramifications 
through many aspects of timekeeping manipulations.


Ah, so who's right?

-Brooks

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-01-31 02:04 PM, Warner Losh wrote:

On Tue, Jan 31, 2017 at 11:58 AM, Brooks Harris <bro...@edlmax.com> wrote:

On 2017-01-31 12:33 PM, Warner Losh wrote:

On Tue, Jan 31, 2017 at 7:54 AM, Steve Summit <scs...@eskimo.com> wrote:

Tom Van Baak and Michael Decker wrote:

2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5

What kind of arithmetic is that?

I think it ends up being roughly the same kind of arithmetic
that tells you that the 60th day of the year is March 1.
Or maybe February 29.

Maybe he's referring to the fact that the offset is 37s, not 36s. The
offset changes AT THE START OF THE LEAP SECOND.

OK, now here's something I've been worrying about for a long time. Everyone
on LEAPSECS, and seemingly everywhere else in the literature, are *sure*
they know exactly what UTC with Leap Seconds is. Yet the specifications are
unclear, as we've been discussing.

Here you are saying "The (TAI-UTC) offset changes AT THE START OF THE LEAP
SECOND. " That is in direct conflict with my best understanding of it. I'd
say "The (TAI-UTC) offset changes immediately AFTER the Leap Second, at the
midnight roll-over to the first second of the next month." (See other email
with my explanation and demonstration code).

That code isn't doing what you think it is, at least imho. By knowing
it's a leap second and adding 1, you've just made a complicated
adjustment that would be unnecessary if the offset changes at the
start of the leap second. Effectively you've "corrected" knowing it's
a leap second by changing the answer by one. That's exactly the same
as saying the offset is one greater one second earlier and eliminating
the special case. In both cases, you have to know that the last minute
has 61 seconds.

Yeah, but I think that's what the specification say.

So, this is obviously a huge interoperablity issue. It has ramifications
through many aspects of timekeeping manipulations.

I don't think so. It's all about how you do the math and the final
answer.
I think its about how you *receive* the information too, not just the 
YMDhms (UTC) result. What information is supplied by NTP or GPS? You've 
got to know exactly when to apply the Leap Second. In the case of a 
hypothetic Leap Second aware timestamp you need the metadata: TAI-UTC 
and one of IsLeapSecond or IsLeapSecondMinute (like a "61" flag) or 
IsLeapSecondDay. But the question is, on which timestamp does TAI-UTC 
increment?

My interpretation leads to simpler math.
Simpler math for what purpose? A bit simpler to calculate YMDhms (UTC) 
maybe, I'd have to work it through. Of course you can treat it anyway 
you like internally as long as two applications wind up with *exactly* 
the same results. But they have to agree when TAI-UTC updates, at least 
as far as any interchange mechanism in concerned, right?



Ah, so who's right?

IMHO, if you do the math out long hand, you'll see I'm right. See
other mail where I walk through it (though perhaps in a difficult to
follow way due to the limits of email).

Warner
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-01-31 02:50 PM, GERRY ASHTON wrote:

...On January 31, 2017 at 7:08 PM Steve Allen  wrote in part:
I prefer to think of a leap second as being truly intercalary.
It is saying to atomic clock "It's not tomorrow yet, wait a second."
It is between one calendar day of UTC and the next calendar day of UTC.
It belongs to neither of them...

UTC is civil time. Civil time is used to express deadlines. Most deadlines fall 
at the end of a calendar day, so which day the 61st second falls in will only 
affect a few time zones, but deadlines may fall on other hour boundaries. So it 
is necessary to know which hour the 61st second belongs to, and I believe it 
belongs to the hour that is about to end.
I don't think anyone disagrees that the Leap Second is the last second 
of a day, "pushing" the midnight roll-over. That's clear from Rec 460. 
But when the TAI-UTC value increments is an important question.


Gerard Ashton
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-02-06 06:30 PM, Tom Van Baak wrote:

I'm not a GPS expert. IS-GPS-200G is dense. The TAI-UTC value is
signaled, but how its encoded is complicated, and when its updated is
unclear to me. See 20.3.3.5.2.4 Coordinated Universal Time (UTC). Can
anyone speak to that and this topic? What does GPS do? Is it clear? Or
does it actually suffer from this same ambiguity we are discussing?

Remember, the alleged ambiguity is only about the what / when of time scale 
integer offsets. There's no ambiguity in TAI or UTC or GPS time stamps 
themselves. GPS receivers tend not to output anything like an offset, so they 
are immune from this discussion.
Sure, GPS navigation relies on GPS time, not UTC. That's the whole point 
of its primary timescale; ignoring UTC for that purpose. PTP does the 
same - UTC is treated as a second class citizen.


Most commercial GPS timing receivers tend to output GPS time or UTC; there are 
internal configuration commands. Their UTC rolls over as one would expect and 
they output 23:59:60 appropriately.
That's where my question is. A GPS receiver would read the UTC metadata 
supplied in the GPS signal to generate UTC 23:59:60 from the primary GPS 
time, right?


We see from this discussion there are several ways folks use to 
calculate this conversion, but what method to use may depend on the 
organization of the metadata.


How is the UTC metadata handled in a GPS receiver? IS-GPS-200G, 
20.3.3.5.2.4 Coordinated Universal Time (UTC) explains a lot, but its 
pretty complicated how the various metadata components are encoded and 
updated. My question is, after decoding and adjusting the GPS data, when 
is the TAI-UTC portion of the metadata updated? At the beginning of, or 
the end of, the Leap Second?

To get TAI one just adds 19 to GPS time. So no worries either way.

Right, but I am still a little worried.

If I were building a GPS-to-PTP receiver/generator, how would I read the 
GPS UTC metadata to populate the PTP UTC metadata? In particular, when 
should timePropertiesDS.currentUtcOffset be incremented? This has 
critical significance to the device receiving the PTP signal if accurate 
UTC is a requirement.




Some cheaper GPS receivers output UTC date and time only, via easy-to-use NMEA 
sentences. In addition, by design, they avoid a 23:59:60 time stamp, which 
would upset upstream instruments. So during a leap second they either output 
23:59:59 twice, or output 00:00:00 twice, or stutter and reset and stumble into 
the next day.

"Stutter and stumble" is not the sort of behavior we're seeking, I hope. :-)

This goes back round to the question of how UTC is mapped into 
86400-second-day systems, such as POSIX time. Does the Leap Second map 
to 23:59:59>23:59:59 (freeze), or 00:00:00>00:00:00 (rollover and reset)?


David Wells says NTP does the first, and POSIX time does the second:

The NTP Timescale and Leap Seconds
https://www.eecis.udel.edu/~mills/leap.html

And, back round to the first question, section 5. How NTP Implements 
Leap Seconds says quite clearly TAI-UTC increments *after* the Leap Second.


-Brooks




Also, NIST Special Publication 250-67 NIST Time and Frequency Radio
Stations:
WWV, WWVH, and WWVB

Yes, there is a bit to indicate a pending leap second at the end of the current 
month. The sign of DUT1 is used to distinguish a positive from a negative leap. 
The data frames used by WWV and WWVB are 60 seconds long.

For a positive leap second a blank second occurs between the last minute of 
2016 and the first minute of 2017. The blank second is definitely not part of 
the 2017 minute. You could argue it's not really part of the 2016 minute 
either; it's just extra second. Again, there's no concept of transmitting a TAI 
offset, so no worries here either.

/tvb
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Negative TAI-UTC

[Brooks Harris]

On 2017-02-04 03:27 PM, Warner Losh wrote:

On Sat, Feb 4, 2017 at 11:12 AM, Brooks Harris <bro...@edlmax.com> wrote:

On 2017-02-04 12:24 PM, Warner Losh wrote:

On Sat, Feb 4, 2017 at 9:41 AM, Clive D.W. Feather <cl...@davros.org>
wrote:

Looking only into the future, not historical data, what do people think
the
probability is that TAI-UTC will ever be negative? Should data structures
be designed to handle this case or not bother?

Doubtful, but not impossible.

LoD would have to increase significantly for that to happen. The
current LoD delta is about 1ms. This looks to vary between -500us to
2ms on IERS' web page (http://hpiers.obspm.fr/eop-pc/index.php).  It
also looks like the short term forecast is to return towards 0 in the
next 150 days or so. Looking at even longer term data from
http://www.usno.navy.mil/USNO/earth-orientation/eo-products/long-term
we see huge error bars for LoD just a few hundred years ago and a big
drop in deltaT from 1850-1900. So the data we have suggests that it is
unlikely, but not outside the realm of possibility.

It's quite likely that the first negative leap second would have a
much higher bug rate than the current positive leap code which has at
least been tested several times and is known to still have issues.

Yes, a negative Leap Second seems especially dangerous to me. How many
devices and applications have been exhaustively tested for that condition?
I'd think the IERS should be especially nervous about issuing a negative
Leap Second. The smears would have to go the other way too.

That's my prediction too. I know that at least some of the code I was
involved with has experienced a negative leap second since we had to
show the contracting office that we could handle a negative leap
second end to end by running our gear in a GPS simulator that lied to
the GPS receiver and told it there was a negative leap second coming.
But I do recall fixing a bunch of bugs to make this possible (by
simulating the GPS putative output and driving the rest of the
software from that). More bugs than I had to fix for positive leap
second testing before 2006...


What if the negative Leap Second possibility was eliminated from the
specification so only positive Leap Seconds were allowed? If the DUT1-to-UTC
<.9s were relaxed, how far from DUT1 might it go? Would it matter, how much,
and to whom?

That would have a rather significant impact on simplification of
implementations, eliminating one whole set of cases and test conditions,
wouldn't it? That could lead to more reliable and uniform behavior, couldn't
it?

I'd say there'd be some objections from people that need UTC to be
within the arbitrary second of DUT1 since their applications assumed
this to be the case and cannot be adjusted somehow. When I started on
this list, I'd say the list is small, but unknown. After years of
doing this, we know there's some telescopes that cost big bucks to
make, but have proprietary software that assumes UTC == UT1 for
initial coarse aiming and the errors in aiming get too large if that
number grows north of a second. There's also talk of sky facing
applications for near earth objects that need this too, but they also
need the IERS rapid forecast group to give them numbers to within a
millisecond. Plus there's an unknown amount of software that checks to
make sure it is < 0.9s (or maybe 1.0s) or that's in old-school FORTRAN
fixed column format that can't overflow. Plus we don't know how large
a negative offset would be, which would make a lot of people nervous.

If we're looking to relax the magnitude of DUT1, perhaps it would also
be time to make the adjustment algorithmically rather than
observationally? That is, lay out a schedule for N years that's
regular as clock work and adjusted on the 'back end' every few years
if the earth is turning significantly faster or slower than the
prediction... However, I'm not so sure that even this small step is
possible.


I agree. I don't think any significant change to the UTC specs can or 
will occur because of reverse compatibility for too many users and 
applications. Killing Leap Seconds, adopting a different schedule of 
introduction, or changing the DUT1 tolerance are all significant 
changes. I asked the question, but the I think answer is we must cope 
with it. And we can. I think the only fix the specs need is *clarity* - 
there's too much room for interpretation.

-Brooks

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-02-01 07:39 AM, Steve Summit wrote:

Brooks Harris wrote:

On 2017-01-31 08:21 PM, Steve Summit wrote:

I feel like I should apologize for my earlier contribution to it,
which presented a nice-looking, persuasive-sounding argument
which now looks an awful lot like it's... wrong.

Not at all. Its an informed contribution. And I think it's not "wrong".
At least not yet. I think its "right", so far.  :-)

On further reflection, I think we're all right.  For every
let's-look-at-the-arithmetic argument that suggests we should
use the "new" offset during the leap second, I can come up with
one which suggests the opposite.  (Basically it depends on
whether you come at the leap second "from below" or "from above".
I'll send the longwinded details in a separate message, if anyone
actually cares.)  So I'm right, and you're right, and Warner's
right, and Steve Allen is especially right in his assertion that
it's just inherently, fundamentally ambiguous.


Yes, well its that "fundamentally ambiguous" part that none of us can 
stand and keeps us obsessed with the LEAPSECS discussion, I guess.


I continue to believe TAI-UTC updates after the Leap Second, at the UTC 
YMDhms midnight rollover. Digging deeper, and once again reading Rec 460:


https://www.itu.int/dms_pubrec/itu-r/rec/tf/R-REC-TF.460-6-200202-I!!MSW-E.doc

Section C Coordinated universal time (UTC) says "UTC is the time-scale 
maintained by the BIPM, with assistance from the IERS..."


This says BIPM is the authority that maintains the UTC timescale, 
doesn't it?


Section E DTAI says "... The TAI - UTC values are published in the BIPM 
Circular T ...".


OK, so, better look more carefully at Circular T.

CIRCULAR T 348ISSN 1143-1393
2017 JANUARY 10, 10h UTC
ftp://ftp2.bipm.org/pub/tai//Circular-T/cirthtm/cirt.348.html

And there we find - "1 - Difference between UTC and its local 
realizations UTC(k) and corresponding uncertainties. From 2015 July 1, 
0h UTC, TAI-UTC = 36 s. From 2017 January 1, 0h UTC, TAI-UTC = 37 s."


I think this clearly says TAI-UTC updates on 2017 January 1, 0h UTC, the 
midnight rollover. This time-point is *after* the Leap Second, isn't it? 
And its authoritatively stated by BIPM.


Meantime, IERS Bulletin C says the same thing - "from 2017 January 1, 0h 
UTC, until further notice : UTC-TAI = -37 s"


https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat

I'm not understanding how this can be interpreted any other way. There's 
nothing ambiguous about it to my reading, and I've had this conversation 
with other good engineers that concur with that reading. It may not be 
convenient for some methods of converting TAI seconds to UTC YMDhms 
representation, but there it is, in black and white, near as I can see. 
It also lines up with all the other IERS Leap Second history data products.


You can't just ignore this because its more convenient. Of course you 
can adjust it internally in a specific implementation as required or 
convenient, in fact you probably need to in some way or other. But the 
data supplied by BIPM and IERS needs to be interpreted consistently, right?


-Brooks


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-02-01 10:12 AM, Steve Summit wrote:

I wrote:

For every let's-look-at-the-arithmetic argument that suggests we
should use the "new" offset during the leap second, I can come up
with one which suggests the opposite.  (Basically it depends on
whether you come at the leap second "from below" or "from above".
I'll send the longwinded details in a separate message, if anyone
actually cares.)

So here's that 2016-12-31 leap second progression again:

row TAI UTC TAI-UTC
1   00:00:3523:59:5936
2   00:00:3623:59:6036? 37?
3   00:00:3700:00:0037

Looking at row 1, everything makes sense.  We can compute
TAI - UTC = TAI-UTC; we can compute TAI - TAI-UTC = UTC; we can
compute UTC + TAI-UTC = TAI.  Everything lines up; everything
is consistent; TAI-UTC is clearly 36.  And similarly for row 3,
where TAI-UTC is just as clearly 37.

But, not surprisingly, row 2 is where everything gets crazy.
:36 is clearly one more than :35, and :60 is clearly one more
than :59, so all the math works out consistently if we keep using
a TAI-UTC offset of 36.  For example, since 00:00:35 - 23:59:59 = 36,
we would have to agree that (00:00:35 + 1) - (23:59:59 + 1) = 36,
meaning that 00:00:36 - 23:59:60 = 36.  This is what I meant by
"coming at it from below".

But if we come at it from above, starting on row 3, we just as
easily get the other answer.  :36 is clearly one less than :37;
:60 is (reasonably) clearly one less than :00.  So if 00:00:37 -
00:00:00 is 37, then subtracting one from both operands gives us
00:00:36 - 23:59:59 which must also be 37.  QEND.
I'm sure we all know to be very careful about zero-based counts v.s. 
one-based counts and how easy it is to make off by one errors. There's a 
bunch of factors in these TAI-UTC value lookups and application to 
YMDhms conversion. When you come at it from top or bottom like that it 
can be confusing for sure.

If we try to convert TAI to UTC on row 2, I absolutely agree with
Warner that 00:00:36 - 36 looks like it ought to equal 00:00:00,
and that 00:00:36 - 37 has a much more likely chance of working
out to 23:59:60.  This is a persuasive, very nearly compelling
argument.
Yes, its convenient that way, from one point of view. But I really don't 
think that's what the specs say (see other email), and the manner the 
data is presented in the Leap Second tables is consistent with TAI-UTC 
updating after the Leap Second. If you need, or want, it the other way 
you can arrange that if you choose, no?. In Warner's case he'd have to 
adjust the incoming TAI-UTC data to suit his needs in some way or other, 
I think, right? Any implementation will probably need to make some sort 
of adjustment in this respect, depending on internal data structures and 
methods employed.



But when I come up at it from below, I can just as
persuasively and almost-compellingly convince myself that the
offset should be 36.

Part of the problem, as Zefram has pointed out, is that when we
attempt to compute 00:00:36 minus anything, we're subtracting a
relative time from an absolute TAI time, which gives us another
absolute TAI time, *not* a UTC time.  So the method is already
suspect.
Yes, there is no uninterrupted incrementing numbering that represents 
UTC. Indeed, that's the whole point, isn't it? UTC = TAI - TAI-UTC, 
right? This will repeat the UTC seconds value:


2016-2017 Leap Second
TAI seconds TAI-UTC UTC seconds
1861920034 - 36= 1861919998
1861920035 - 36= 186191
1861920036 - 36= 186192
1861920037 - 37= 186192
1861920038 - 37= 1861920001

That's what it does. That's what its *intended* to do. That's the 
information by which the Leap Second is *encoded* into the UTC YMDhms 
representation. 1861920036 - 36  = 186192 is the Leap Second, and 
that's where the YMDhms sequence must read 2016-12-31 23:59:60 by 
whatever means necessary.


It is of course not a consistent mathematical relationship; its a 
purposely applied discontinuity to adjust the UTC YMDhms label. The UTC 
YMDhms is an *encoding* of the TAI seconds value. That's what UTC is, 
right?




The leapsecond-handling code I've been writing recently is based
around a table that can tell me, for a given (UTC) timestamp,
what the day length and TAI offset are for the UTC day containing
that timestamp.  Given that architecture, I pretty much have to
have the TAI offset for the last second of a leapsecond day
matching the other 86400 seconds on that day.  When, belatedly,
I attempted to write a TAI-to-UTC conversion function last week,
I had problems with the leap second; I had to introduce a
kludgier and less-obvious special case than I expected to.  I now
realize that Warner is right: if TAI-UTC were one greater during
that second, the code would be a little cleaner.  But (in my case,
at least) there would be a substantial, and considerably greater,
amount of code elsewhere that 

Re: [LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-02-06 12:11 PM, Warner Losh wrote:

On Mon, Feb 6, 2017 at 6:39 AM, Zefram  wrote:

Warner Losh wrote:

So either there's some weird math that lets one subtract two numbers
that are different and get 0 as the answer, or the delta has to change
at the start.

To the extent that they're different, the things being subtracted are
not numbers.  The expression "TAI - UTC" is shorthand for something more
complicated than a numeric subtraction, which will nevertheless produce
a numeric result.  The linear reduction of a timestamp that Clive and
I have separately described is sufficiently numerical to admit of a
straightforward subtraction, and the linear reductions of N:23:59:60 and
(N+1):00:00:00 are duly the same.

Saying that the two numbers are the same is improper. Or rather, it
depends on which time scale you are looking at them in if they are
improper. In UTC they are clearly not the same, but different second
labels. UTC can express this non-sameness. TAI can't do that, so you
have to reduce the improper time to a proper one before you can
compare them. There's two ways to look at it: convert them both to TAI
or convert them both to UTC.

So, if you look at the two times in TAI land, you have to do that
folding of seconds that's implicit in the linearization formula. If
you do that folding of seconds, then the 60 in the irregular radix
takes care of the difference in the first second since you've folded
its value to the value of the first second of the next day. That means
you have to say the difference starts after the leap second.

However, if you look at the two times in UTC land and compute a delta
in UTA land, then you find the interval between N:23:59:60 and
N+1:00:00:00 you wind up with 1 second. That leads to the conclusion
that the difference starts at the beginning of the leap second.

The whole discussion about when the difference starts can be boiled
down to that. What's the proper way to look at it? Depends on how you
do the math to do the conversion to when you use the new offset.


An analogy: suppose we do a bit of arithmetic in hexadecimal.  We can
all agree that 0x5a0 - 0x5a0 = 0x0.  Suppose that while keeping the
hexadecimal radix we additionally use the digit "g", with value sixteen.
Now we find that 0x5a0 - 0x59g = 0x0.  The difference is zero, yet the
numbers appear different.  What's going on?  Well, the numbers per se
are the same: 0x5a0 = 0x59g is a single numerical value.  The things
that are different are the digit sequences "5a0" and "59g", which under
the convention being used here are two different ways of expressing that
single number.  The digit sequences are not themselves numbers.

I think now you're getting confused about irregular radix. If we were
to do that with hex, the number 0x59g would be a non-normalized number
that normalizes to 5a0 because hexadecimal is a regular radix. You
can't normalize N:23:59:60 to N+1:00:00:00 because in UTC they are two
different second labels.

Put another way: it's indisputable that if I have one event at
N:23:59:60.1 and a second event at N+1:00:00:00.6, they happened 1.5s
apart.

Also, I'll note that bulletin C says from 0h, which is a time
expressed to only one significant digit.
Oh yeah. Good point. For me, a case of "filling in facts from common 
understanding". I immediately interpret "0h" to mean "00:00:00". Maybe not?

They chose to not use the
unambiguous 00:00:00 opting for the less precise 0h.
But its unclear if it was an intentional choice. Maybe they do mean 
"00:00:00" by "0h"?


There are lots of places in many specs everywhere where things are not 
fully spelled out. Sometimes its unclear if this is just due to slightly 
careless nomenclature. There's a tendency to try to write prose 
concisely, and sometimes this leads to something less clear than it 
should be. If you've been in debates in standards bodies you know what I 
mean. Writing standards prose is hard, and people don't always agree on 
writing style, etc. especially when some participants are not from 
native English speaking countries. The UTC specs have that challenge in 
spades, so we could be seeing some effects of that in the English prose.

If you make the
second folding argument via time linearization, you map both the leap
second and the first second of the next day to the same value. Which
one of those is 0h?

I think the final answer is: It's ambiguous and I was wrong to insist
that there's one true way to recon it.


Who ya gonna call? It would be helpful if someone from BIPM, IERS, or 
ITU would weigh in on the topic.


Another way to answer the question is to ask what's the common practice? 
In my discussions regarding 1588/PTP the consensus was "the spec says 
after the Leap Second" and most in the 1588/PTP community interpreted in 
that way, that implementations would increment the 
timePropertiesDS.currentUtcOffset after the Leap Second, the same 
instant timePropertiesDS.leap61 would be set FALSE. The SMPTE specs 

Re: [LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-02-03 11:24 PM, Tom Van Baak wrote:

Hi Warner,


But consider TAI and UTC when they were equal, for the sake of
argument. I know they never were, but if we look at what the first one
would look like:

That's a nice, clear example. Thanks.


23:59:58 23:59:580
23:59:59 23:59:590
00:00:00 23:59:601
(since how can it be 0 if they are different?)

Ah, the offset can be 0 *because* they are different. In fact, the offset 
*must* be 0. You see, there's no need for *both* the :60 *and* the 1 offset at 
the same time. Each of them on their own are capable of indicating a one second 
difference from normal:
- A :60 by its unique value tells you there is a now an offset of +1 second in 
the time scale.
- And dTAI being 1 tells you there is now an offset of +1 in the time scale.

You don't need *both* of them. When you're in a leap second, the extra-normal 
value of the :SS itself tells you an offset. And when you're not in a leap 
second that information carries over to dTAI to tell you the offset. Their 
*sum* at any instant is the difference between the time scales.


So either there's some weird math that lets one subtract two numbers
that are different and get 0 as the answer, or the delta has to change
at the start.

It's understanding what the weird math is that I'm having trouble with
for people that say it is after the leap second that the delta
changes.

Well, yes, it is sort of weird math. It's operations on time stamps, not 
integer counts of seconds. Look at it this way:
- In decimal arithmetic you have 10 symbols, so you carry when you pass 9. If 
you wrap from 9 to 0 and do not carry you've lost count.
- In seconds arithmetic you have 60 symbols, so you carry when you pass 59. If 
you wrap from 59 to 00 and do not carry you've lost count.

Further, UTC is not just regular time stamps. Leap seconds are clever. They invent a new 
symbol, called "60". This symbol, by its very existence, holds a new count 
without actually carrying. It allows you to postpone the carry until you are ready to 
wrap to 00. Once you wrap, though, something else needs to keep track of that extra count 
or you'll lose count. And that something is dTAI.

So this means the time scales physically diverge at the beginning of the 
negative or positive leap second, but the integer value of dTAI doesn't 
increment until you're finished with the time stamp(s) that have excess-60 in 
them; that is, at the moment you roll over to :00.

Remember, the pseudo math you're trying to solve is something like this:
TAI = UTC + (TAI-UTC)

It's not being done with integers, in decimal or in hex; it's not even being done in mixed-radix 24:60:60 format. Instead it's 
being done with an optional extra symbol. So the "equation" is always true. It's just that once in a while, during a 
positive leap second, the value of the "UTC" in the equation (via use of an extra symbol) is 1 greater than usual. To 
keep the equation true, the value of "TAI-UTC" remains the same while this happens. It's only when the time stamp rolls 
over to :00, that the extra 1 moves over from the "UTC" part to the "TAI-UTC" part of the equation.

/tvb
This is where I've called it an "encoding". Its not just math. UTC has 
this extra, irregularly introduced, encoding factor.


In SMTPE timecode, the hh:mm:ss:videoframes (hmsf) representation is an 
encoding of the number of video frames since a zero origin. The origin, 
and the hmsf values have nothing to do with the calendar or time-of-day; 
they are just incrementing counts since an abstract "zero".


If the video frame rate is 25/1 (the PAL (Phase Alternate Line) 
standard, used in Europe and elsewhere), there are 25 frames per *true 
SI second*. In a frames count value encoded as hmsf the hh:mm:ss behaves 
as you'd expect, incrementing the seconds every 25 frames, the minutes 
every 60 seconds, etc. The hmsf is an encoding of the number of frames, 
for example 01:00:00:00 is 90,000 frames (3600 seconds * 25 
frames-per-second = 90,000 frames). Its a straight forward encoding 
using the "24-hour timekeeping system" as ISO 8601 calls it (ss = s, mm 
= 60s, hr = 60mm, day = 24hr).


00:59:59:23 = 89998 frames
00:59:59:24 = 8 frames
01:00:00:00 = 9 frames
01:00:00:01 = 90001 frames

The hmsf representation is a deterministic encoding of 90,000 1/25 
frames-per-second frames. And the hh:mm:ss portions will increment in 
true time, so the running time is indicated by the hmsf values which is 
very familiar and handy for humans to read and use.


But with the NTSC (National Television Standards Committee) standard 
used in the US, Japan, and elsewhere, things are a bit more tricky. The 
NTSC frame rate is 3/1001. This is approximately ~29.97 frames per 
true SI second. That 1001 denominator is *evil* - the frame rate is 
actually a repeating decimal number; 

Re: [LEAPSECS] Negative TAI-UTC

[Brooks Harris]

On 2017-02-04 12:24 PM, Warner Losh wrote:

On Sat, Feb 4, 2017 at 9:41 AM, Clive D.W. Feather  wrote:

Looking only into the future, not historical data, what do people think the
probability is that TAI-UTC will ever be negative? Should data structures
be designed to handle this case or not bother?

Doubtful, but not impossible.

LoD would have to increase significantly for that to happen. The
current LoD delta is about 1ms. This looks to vary between -500us to
2ms on IERS' web page (http://hpiers.obspm.fr/eop-pc/index.php).  It
also looks like the short term forecast is to return towards 0 in the
next 150 days or so. Looking at even longer term data from
http://www.usno.navy.mil/USNO/earth-orientation/eo-products/long-term
we see huge error bars for LoD just a few hundred years ago and a big
drop in deltaT from 1850-1900. So the data we have suggests that it is
unlikely, but not outside the realm of possibility.

It's quite likely that the first negative leap second would have a
much higher bug rate than the current positive leap code which has at
least been tested several times and is known to still have issues.
Yes, a negative Leap Second seems especially dangerous to me. How many 
devices and applications have been exhaustively tested for that 
condition? I'd think the IERS should be especially nervous about issuing 
a negative Leap Second. The smears would have to go the other way too.


What if the negative Leap Second possibility was eliminated from the 
specification so only positive Leap Seconds were allowed? If the 
DUT1-to-UTC <.9s were relaxed, how far from DUT1 might it go? Would it 
matter, how much, and to whom?


That would have a rather significant impact on simplification of 
implementations, eliminating one whole set of cases and test conditions, 
wouldn't it? That could lead to more reliable and uniform behavior, 
couldn't it?


-Brooks




Warner
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-01-31 02:53 PM, Warner Losh wrote:

On Tue, Jan 31, 2017 at 12:41 PM, Brooks Harris <bro...@edlmax.com> wrote:

On 2017-01-31 02:04 PM, Warner Losh wrote:

On Tue, Jan 31, 2017 at 11:58 AM, Brooks Harris <bro...@edlmax.com> wrote:

On 2017-01-31 12:33 PM, Warner Losh wrote:

On Tue, Jan 31, 2017 at 7:54 AM, Steve Summit <scs...@eskimo.com> wrote:

Tom Van Baak and Michael Decker wrote:

2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5

What kind of arithmetic is that?

I think it ends up being roughly the same kind of arithmetic
that tells you that the 60th day of the year is March 1.
Or maybe February 29.

Maybe he's referring to the fact that the offset is 37s, not 36s. The
offset changes AT THE START OF THE LEAP SECOND.

OK, now here's something I've been worrying about for a long time.
Everyone
on LEAPSECS, and seemingly everywhere else in the literature, are *sure*
they know exactly what UTC with Leap Seconds is. Yet the specifications
are
unclear, as we've been discussing.

Here you are saying "The (TAI-UTC) offset changes AT THE START OF THE
LEAP
SECOND. " That is in direct conflict with my best understanding of it.
I'd
say "The (TAI-UTC) offset changes immediately AFTER the Leap Second, at
the
midnight roll-over to the first second of the next month." (See other
email
with my explanation and demonstration code).

That code isn't doing what you think it is, at least imho. By knowing
it's a leap second and adding 1, you've just made a complicated
adjustment that would be unnecessary if the offset changes at the
start of the leap second. Effectively you've "corrected" knowing it's
a leap second by changing the answer by one. That's exactly the same
as saying the offset is one greater one second earlier and eliminating
the special case. In both cases, you have to know that the last minute
has 61 seconds.

Yeah, but I think that's what the specification say.

All the specifications says is that positive leap seconds cause the
minute to have 61s.

Yes, Or the day 86401, etc.



So, this is obviously a huge interoperablity issue. It has ramifications
through many aspects of timekeeping manipulations.

I don't think so. It's all about how you do the math and the final
answer.

I think its about how you *receive* the information too, not just the YMDhms
(UTC) result. What information is supplied by NTP or GPS? You've got to know
exactly when to apply the Leap Second. In the case of a hypothetic Leap
Second aware timestamp you need the metadata: TAI-UTC and one of
IsLeapSecond or IsLeapSecondMinute (like a "61" flag) or IsLeapSecondDay.
But the question is, on which timestamp does TAI-UTC increment?

It increments just prior to the positive leap second. It doesn't
matter how you get the information. That's when the offset needs to
change for the irregular radix math to work.

Or put less authoritatively: why would it matter how you get the
information? A second is either a leap second or it isn't, right? And
the property of a second that makes it a leap second in UTC is that's
when the offset changes against TAI.

We know that

UTC = TAI + UTC_OFFSET(TAI)

Since UTC is an irregular radix, the math is a little complicated, but
the only way for the above to work out is if UTC_OFFSET(TAI) changes
at the start of the leap second. So going from 36 to 37, the way you
get :60 is by subtracting 37 from TAI instead of 36.
Right. Well if you have TAI-UTC = 36 and a "IsLeapSecond" flag its just 
TAI-UTC = 36 + IsLeapSecond = 37.



My interpretation leads to simpler math.

Simpler math for what purpose? A bit simpler to calculate YMDhms (UTC)
maybe, I'd have to work it through.

It's the only way to encode one number such that the irregular radix
math works out.
I think I'm going to need an example I can work through to fully 
understand you here. When you get a chance, or can point me to 
something, thanks.

And treating a positive leap second 'special' that
needs an extra decrement is isomorphic to changing the delta at the
start of the second.
Ah, well the Leap Second is special, isn't it, even from the point of 
view of your "irregular radix
math"? You are detecting it by whatever means and then treating it as if 
the TAI-UTC value incremented and the start of the Leap Second so its 
convenient to your methods, right? I mean, how its detected and treated 
could be seen as an internal implementation choice.


My "IsLeapSecond" flag can also be generated internally so long as there 
is adequate metadata, either a IsLeapSecond or IsLeapSecondMinute, or 
IsLeapSecondDay or something. But in any case you still need the TAI-UTC 
value.


The simple TAIToUTCDemoConsole program is not exactly how I do it in 
more elaborate code, but, generally I aim to do everything with integer 
math and logic.


I wrote the little program to illustrate the resulting values, 
especially the UTC seconds value, to explain what I meant b

Re: [LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-01-31 03:52 PM, GERRY ASHTON wrote:

How I would interpret "offset":

Bulletin C 52

The difference between UTC and the International Atomic Time TAI is:

   from 2015 July 1, 0h UTC, to 2017 January 1 0h UTC   : UTC-TAI = - 36s
   from 2017 January 1, 0h UTC, until further notice: UTC-TAI = - 37s
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs



Yes, me too. I think that's what Bulletin C is saying.

-Brooks
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-02-01 12:46 PM, Steve Allen wrote:

On Wed 2017-02-01T10:50:12 -0500, Brooks Harris hath writ:

https://www.itu.int/dms_pubrec/itu-r/rec/tf/R-REC-TF.460-6-200202-I!!MSW-E.doc

Section C Coordinated universal time (UTC) says "UTC is the
time-scale maintained by the BIPM, with assistance from the IERS..."

This says BIPM is the authority that maintains the UTC timescale,
doesn't it?

Yes, but that is a "grandfathered" arrangement with a history.
TF.460-6 is a rewrite from the original Rec.  460 which placed all
authority with the BIH (International Time Bureau).

In 1972 J. Terrien (the director of the BIPM who had been at the IAU
meetings on radio broadcast time signals since 1964) noted that "the
BIPM does no experimental work on the measurement of time and
frequency" and apologized that "regrettable misunderstandings,
especially between astronomers and physicists, have crept into
discussions on time and frequency."

That is to say that at the inception of leap seconds the BIPM
had no component which could have defined a time scale.

The advent of atomic chronometers made the role of the BIH unclear.
The precision of satellite and interferometric measurements of the
earth compounded this cloudiness.  BIH had oversight of axial rotation
of earth, and two other agencies had oversight of the motion of the
pole of earth.  That distinction made sense in 1920, but not by 1980.

The overseeing astronomical and geophysical agencies decided to
rearrange the divisions of responsibility beginning with 1988.  BIH
and the two polar motion organizations were abolished.  The atomic
chronometers went to BIPM.  All of the earth orientation went under
the umbrella of IERS.  The CCIR got reorganized into the ITU-R in
1992, the recommendations were not revised for years after that.  None
of the agencies who currently have responsibility existed when all
this started, and the documents still do not quite describe how things
actually work.
Right, thanks. It is a fascinating history, if somewhat frustrating when 
searching for a practical answer.


So, BIPM is the current authority of maintenance of TAI and UTC ("with 
assistance from the IERS"), is that right? And IERS makes their 
procedures for "assistance" known through the IERS Conventions?. And ITU 
and Rec 460 is the authority for "Standard-frequency and time-signal 
emission"? And Rec 460 points at BIPM Circular T.


As I read it there is, in fact, a chain of provenance through this even 
though its not so obvious. Of course, as I said, I think the facts are a 
scattered around and takes far to long to discover how it ties together, 
and I wish I had more confidence in my conclusions.


What's your opinion of the TAI-UTC value update topic? At or after the 
Leap Second?


-Brooks



--
Steve Allen<s...@ucolick.org>  WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street   Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064   http://www.ucolick.org/~sla/   Hgt +250 m
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-01-30 10:12 AM, Steve Allen wrote:

On Mon 2017-01-30T14:14:10 +, Tony Finch hath writ:

I think what I was trying to get at (as others have already said in this
thread) is that you can use the TAI-UTC delta to translate from UTC to TAI
during a leap second, but you need more information to make the inverse
translation.

As mentioned by Arias in that radio show, there are leaps of one hour
in time that we deal with regularly.  The tz project has tzdata that
unambiguously represent when the jump occurs, and the tzcode has a
convention for how to interpret the ambiguous hour.

(One thing tz cannot do is represent the legal specification of the
changes in Spain a century ago when the time of fall back was given
by the decree as 25:00:00 on the date in question.  tz encodes
those as 01:00:00 on the next date.)
Indeed, while we debate the exact subtle meanings of UTC and Leap 
Seconds the potential inaccuracies of UTC implementations are 
overwhelmed by the potential inaccuracies of local time, both in terms 
of magnitude (1 second TAI-UTC v.s (at least) one hour DST) and in terms 
of clarity of standardization (UTC is pretty well defined, while 
specifications of local time is something of the wild west).


It seems to me Tz Database does a great job of describing the meanings 
of local time after 1972, thanks to the diligent and obsessive work by 
its authors and contributors. As far as I can see, it describes local 
time for contemporary timekeeping, albeit with some quirks and 
exceptions. It has become a de facto standard.


Describing local time before 1972 is going to be a challenge. When was 
the Gettysburg Address delivered? Exactly how was local time understood 
at the time and how would it relate to modern timekeeping practice? This 
is an interesting, fascinating, and probably valuable exercise, but if 
we get too tangled up in those considerations we risk diverting 
attention and energy from the more urgent need of arriving at a uniform 
treatment of local time in contemporary timekeeping systems.


Time Zone Database has become a de facto standard, and IANA's 
involvement has lent it further credibility. But:
A) its only a de facto standard - a due-process standardization process 
is required to achieve world-wide adoption

B) its documentation could be improved because it is complex and quirky
C) its data relies on the reports and judgements of contributors and 
there is no formal process for registering changes
D) its c implementation code is dated and relies on POSIX-time type 
functions and heritage which complicates incorporating Leap Seconds


This is not in anyway a criticism of the years of development in Tz 
Database - its really a fantastic piece of work, hats off.  I only wish 
and hope it will be improved.


-Brooks



--
Steve Allen  WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street   Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064   http://www.ucolick.org/~sla/   Hgt +250 m
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-01-30 03:45 PM, Michael.Deckers. via LEAPSECS wrote:



   On 2017-01-30 19:21, Tom Van Baak wrote:


2017-01-01T00:00:36.5 - 36 s = 2016-12-31T23:59:60.5

   What kind of arithmetic is that?
Its not arithmetic. Its a YMDhms encoding of a TAI second. The Leap 
Second (TAI-UTC) metadata from Bulletin C is describing how the encoding 
is to be done. You need to know the Leap Second metadata to do the 
conversion from TAI seconds to UTC YMDhms.





2017-01-01T00:00:37.5 - 37 s = 2016-12-31T00:00:00.5


  The question was whether 2017-01-01T00:00:36.5 - 37 s
  is < 2017-01-01 or >= 2017-01-01.


Its not a mathematical relationship. Its an encoding scheme. You need 
the Leap Second metadata -


2017-01-01T00:00:36.5 (TAI) - 36 s [and the fact its a Leap Second] = 
2016-12-31T23:59:60.5 (UTC).


-Brooks



  Michael Deckers.


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-01-30 01:12 PM, Michael.Deckers. via LEAPSECS wrote:


  On 2017-01-30 13:06, Tony Finch wrote:



It's tricky. Bulletin C is pretty clear about when it thinks TAI-UTC
changes:

   from 2015 July 1, 0h UTC, to 2017 January 1 0h UTC   : UTC-TAI = - 
36s
   from 2017 January 1, 0h UTC, until further notice: UTC-TAI = - 
37s



   Pretty clear? Let's try. What does Bulletin C52 say about the
   relationship between UTC and TAI when TAI is equal to
   2017-01-01T00:00:36.5. Obviously, UTC - TAI at that instant
   must be either -36 s or -37 s.

   • If it is -36 s, then UTC = TAI + (UTC - TAI) = 
2017-01-01T00:00:36.5 - 36 s

 = 2017-01-01T00:00:00.5. This is > 2017-01-01, so by Bulletin C52,
 UTC - TAI = -37 s, contradiction.


It looks like you intend that "2017-01-01T00:00:36.5" to be a YMDhms 
representation of TAI, a pure Gregorian representation with no Leap 
Second compensation applied. If so, simply subtracting 36 doesn't result 
in a correct UTC YMDhms. Its not a simple mathematical relationship. 
That second value, 2017-01-01T00:00:36.5 (TAI), lies within the Leap 
Second, so the corresponding UTC would be 2016-12-31T23:59:60.5  (UTC). 
To know how produce the correct UTC YMDhms you must have access to the 
Leap Second metadata prior to the Leap Second introduction. That's what 
Bulletin C is telling us.
   • If it is -37 s, then UTC = TAI + (UTC - TAI) = 
2017-01-01T00:00:36.5 - 37 s

 = 2016-12-31T23:59:59.5. This is < 2017-01-01, so by Bulletin C52,
 UTC - TAI = -36 s, contradiction.


   Fact is, the statement of Bulletin C52 cannot be true when the 
value of

   TAI is during a positive leap second, but it doesn't say so.
   So yes, pretty tricky.


But I agree its a little tricky. It seems to me this is where the UTC 
specifications are scattered over many documents and no one document 
makes it clear by itself, and this leaves room for misunderstanding.


If you look at ITU-R Rec 460, ANNEX  3, Dating of events in the vicinity 
of a leap-second, its pretty clear the positive Leap Second is 
introduced as last the second of the day of the last day of the month 
and is labeled 23:59:60. But it doesn't say clearly when the Leap Second 
accrues to the TAI-UTC value.


It you look at Bulletin C, and/or other BIPM and IERS products listing 
TAI-UTC history, and consider their values carefully in the context of 
Rec 460 you can conclude the positive Leap Second occurs at the end of 
the day and the Leap Second doesn't accrue to the TAI-UTC value until 
immediately after the Leap Second has past, coincident with the midnight 
roll-over to the next day.


I concur with Steve Summit's earlier conclusion about the h:m:s sequence 
and the corresponding TAI-UTC values - (his example was for the 2015 
June/July Leap Second)


Positive leap second:

TAI   UTC   TAI-UTC
00:00:34.023:59:59.035
00:00:34.523:59:59.535
00:00:35.023:59:60.035
00:00:35.523:59:60.535
00:00:36.000:00:00.036
00:00:36.500:00:00.536

I think this is how most people and implementations interpret it. But 
its just not nearly as clear as it ought to be!


Rec 460 doesn't state clearly when the Leap Second accrues to the 
TAI-UTC value with respect to a YMDhms representation, although it does 
say "2.2 A positive leap-second begins at 23h 59m 60s and ends at 0h 0m 
0s of the first day of the following month." Also note TAI-UTC is called 
"DTAI" in Rec 460; "E DTAI - The value of the difference TAI – UTC ...".


Bulletin C says "Leap seconds can be introduced in UTC at the end of the 
months of December or June". I suppose the phrase "the end of the month" 
could be interpreted to mean the same as Rec 460's more complete 
explanation of when Leap Seconds are introduced. In addition, "of 
December or June" is arguably different from Rec 460's "A positive or 
negative leap-second should be the last second of a UTC month, "


Also, Rec 460 calls DTAI "TAI-UTC" and this implies TAI-UTC is a 
positive value, while Bulletin C gives the values as negative "UTC-TAI".


Cross checking with other TAI-UTC sources is not immediately helpful.

You encounter MJD in IERS 
https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat
You encounter NTP seconds in NIST 
ftp://utcnist.colorado.edu/pub/leap-seconds.list


If anyone at BIPM, IERS, or ITU-R is listening, it would be really good 
to have a single source specification for UTC, or, failing that, at 
least bring the documents in line with one another.


-Brooks













   Michael Deckers.

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] BBC radio Crowd Science

[Brooks Harris]

On 2017-02-09 02:28 AM, Warner Losh wrote:

On Fri, Feb 3, 2017 at 4:30 PM, Brooks Harris <bro...@edlmax.com> wrote:

If its after the Leap Second then your method doesn't work directly; you'd
need to figure it out and make an internal adjustment to the TAI-UTC value a
second *before* its supplied to you, right? See what I mean?

That would be a problem, yes. However, how do you know it is a leap
second w/o TAI-UTC changing? You'll need that metadata from elsewhere.
Yes. The need for the metadata in some form is unavoidable because the 
Leap Seconds are irregularly introduced in the past (history) and 
unpredicatble when they will be introduced in the future (announce 
and/or expiration). That's the whole point of it. Its not just 
mathematical. Its an algorithm that is partly mathematically calculable 
for the Gregorian part, but also requires the additional UTC metadata as 
an input to arrive at UTC YMDhms (or the reverse). That's where I've 
called it an "encoding". I'm not sure "encoding" is the best term, but 
the best I've found. Writing about the stuff in prose is difficult 
because so many different terms are used by so many folks from different 
backgrounds.

To do the leap second correctly, though, you'd need some warning
before the leap second  that it will, in fact, be a leap second.
Yes. That's where I illustrated using an "Is Leap Second" flag. How an 
"Is Leap Second" condition is detected depends partly on what you're 
dealing with. If the complete Leap Seconds table, announce, and 
expiration are available to you its simple enough - the Leap Second is 
the second *before* the [UTC date][TAI-UTC] as presented by the Leap 
Second tables. But if you're dealing with a real-time time-link protocol 
(GPS, PTP, NTP) you're either dependent on the UTC metadata supplied by 
the time-link, or you need to go elsewhere somehow to collect it. 
Unfortunately, each of those protocols use slightly different formats 
and terms for the variables and not all carry the TAI-UTC directly, only 
announce flags. This situation is a result of historical development in 
an environment lacking clear specification.


I'd love to know which spec actually states the offset changes where
you say, since it would resolve the ambiguity.
I don't think there is any that states it unambiguously. As we've 
discussed, ITU Rec 460 doesn't state this, and BIPM Circular T and IERS 
Bulletin C only *imply* it by their [UTC Date][TAI-UTC] values. What 
you'd wish to find is a clear statement like "The TAI-UTC value shall 
update immediately after the Leap Second, coincident with the midnight 
rollover of the UTC YMDhms date". Seems to me the best place for a 
statement like this would be in Rec 460, and if it existed it would head 
off misunderstanding.


But there is much "common practice" that follows, or at least seems to 
follow, that interpretation. As I've said I've heard it discussed and 
the consensus was that interpretation.


The one place I've seen it made very clear is by David Mills regarding 
NTP, and he extends the analysis to POSIX. This is, off course, only 
David Mill's explanation, not a dues-process specification, but his 
considerable authority lends weight.


The NTP Timescale and Leap Seconds
https://www.eecis.udel.edu/~mills/leap.html

Figure 1. NTP Leap Second Numbering shows the "TAI offset" incrementing 
after the Leap Second


Figure 2. NTP Offset In the Vicinity of a Leap Second shows it 
graphically, and the TAI-UTC value incrementing after the Leap Second. 
However, even here there's a bit of vagueness; note that the arrow of 
the preceding TAI-UTC value does not extend through the Leap Second to 
the midnight boundary.


We're not the only ones confused about this, as you know - I found this 
discussion -


Re: [AVTCORE] Leap seconds
https://www.ietf.org/mail-archive/web/avt/current/msg14829.html


Absent a spec, the
closest thing is decades of Bulletin C.

However, I owe Zefram an apology for being overly grumpy. I thought he
was being deliberately obtuse. In reality, his question TAI-UTC at
23:59:59 proved the undoing of what I was advocating. I'm sorry I
snapped at him. It was uncalled for.
Any technical topic is loaded with opinion and bias, but timekeeping is 
in a league of its own in eliciting passion and debate. Practical 
technical issues become entangled in discussions of Relativity, Quantum 
Mechanics, spirituality, mysticism, and cultural world view. Native 
languages add another level of potential misunderstanding. The standards 
are maintained by international standards bodies that contend with 
international politics and cultures which may add whole other levels of 
complexity not directly connected to the technical details.


For the most part those of us on this list are seeking academically 
correct practical technical solutions. The terms and expressions are 
important, and sometimes are misleading if 

Re: [LEAPSECS] Bloomberg announced its smear

[Brooks Harris]

On 2016-09-26 10:23 AM, Tony Finch wrote:

Brooks Harris <bro...@edlmax.com> wrote:

The short of it is Windows behave just like POSIX as far as I can tell,
except its epoch, represented as struct FILETIME, is 1601-01-01T00:00:00
(UTC-like), which is, apparently the COBOL epoch (I didn't track down
the references on that).

It turns up when converting formatted dates to integer count-of-days.

http://community.microfocus.com/microfocus/cobol/extend_and_acucobol/f/20/t/9565.aspx
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceea300/clccbld.htm
I've seen a couple explanations of "January 1, 1601" epoch, for 
example,  this mentions "The ANSI Date defines January 1, 1601 as day 1, 
and is used as the origin of COBOL integer dates. "


What is the significance of January 1, 1601?
http://stackoverflow.com/questions/10849717/what-is-the-significance-of-january-1-1601

I didn't try to find the relevant "ANSI Date" definitions, if they exist.

-Brooks



Tony.


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Bloomberg announced its smear

[Brooks Harris]

Hi Tom, Stephen and Stephen;

Adding to Stephen Scott's comments...

On 2016-09-24 11:39 AM, Stephen Scott wrote:

Hello Tom, Stephen;


On 2016-09-24 08:26, Tom Van Baak wrote:

Stephen,


As I've been saying for years, what we need (desperately) is a
standard for smearing, aka 86400 subdivision days.
That's sort of where we were before there were leap seconds. The 
second used for UTC clocks was shifted slightly from the second SI.
But that's part of the charm in smearing -- that there's no one way 
to do it, and you're free to modify it as you wish.

That's called anarchy.


My preference is UTC-SLS, but I don't really care so long as it is 
an agreed standard.
UTC-SLS has always been a good example why an inflexible academic 
standard is a bad idea.



I know that many find smearing offensive, but its timet o move on and
get the standard written.

Stephen
Smearing is fine. It's a practical solution to an intractable 
problem. But forcing everyone to implement it the exact same way 
misses the point. You can't create a standard for your favorite set 
of time applications and then try to force it upon everyone else's 
time applications.

Smearing is fine if you don't depend on a second being a second.
I work in the broadcast industry where time synchronization is 
critical. Television is fundamentally developed as a synchronous 
process from glass to glass. Radio and TV broadcasts are a major means 
of disseminating time.
The challenge here is that the broadcast industry needs fixed-epoch 
deterministic local timescales to accomplish media (video and audio) 
timekeeping. The broadcast industry also faces the requirement of 
handling many media-related frequencies,  including audio sample rates 
those related to the NTSC frame rate of 3/1001. That 1.001 second 
denominator is a nasty number to cope with.




The problem is not the leap second. The problem is that every local 
authority is free to incorporate the leap second when and how they 
wish and even then end users deviate from that is that is not 
convenient. There is no international standard or even a convention 
that could be followed. The lack of these standards is what is 
promoting Smear Type 1, Smear Type 2, Smear Type 3, etc.
Fundamentally, the early implementations of POSIX and the many systems 
based on its heritage cannot represent "23:59:60" and so most systems 
are *indeterminate* at (or near) the Leap Second. Related factors and 
implementations have created mismatched, and, in some cases buggy, 
systems.  Smear is introduced to "hide" the Leap Second from the 
downstream systems to avoid, or mitigate, the difficulties, including 
system failures. The smear introduces yet another longer period of 
indeterminate timestamps.


Meantime, the very many definitions of local time (time zones) and 
Daylight rules are hugely complex and somewhat unpredictable and 
uncontrollable. And with at least two major sources for zone zone 
information in the field, Tz Database and Microsoft, more complexity and 
mismatched information is introduced in the challenge.


The difficulty of the local time topic overwhelms the the challenge of 
Leap Seconds, both in terms of political and technical agreement and in 
the magnitude of the likely errors and inaccuracies. "Fixing Leap 
Seconds" is necessary but insufficient to solve the local time problems.


So here we are;

* Leap Seconds are with us in the international time and dissemination 
standards and master clocks for at least another decade, probably much 
longer.


* A bazillion systems and devices are in the field that cannot reliably 
or accurately handle Leap Seconds


* The three (at least) smear systems are up and running, helping 
mitigate system failure of down-stream systems within their own realm, 
but are mismatched.


* Microsoft has taken another approach to Leap Seconds with Azure, 
incompatible with the smears.


* IANA has taken responsibility for Tz Database, but its not standardized.

* Microsoft has their own (proprietary) time zone mechanisms, only 
partly compatible with Tz Database.


In the medium term, I think it would be helpful if the smear systems 
were the same. At least you could determine which time-points were part 
of the smear and thus indeterminate. As it stands you have to assume the 
broadest span (24 hours around midnight) and that no timestamp in that 
range can be trusted. But somebody else could use yet another 
formulation, and then its even more unreliable. Some standardized 
guidance document could help.


In the long run, the industry, and society in general, is going to have 
to come to grips with the issues. This will ultimately require a set of 
standards running all the way from the BIPM, IERS, and ITU 
specifications, through the master clocks and time dissemination 
protocols, to receiving systems and file system timestamps. That will 
take many years. But if it doesn't happen the electric civilization is 
going to encounter increasing 

Re: [LEAPSECS] Bloomberg announced its smear

[Brooks Harris]

Warner,

On 2016-09-24 06:02 PM, Warner Losh wrote:

On Sat, Sep 24, 2016 at 3:46 PM, Hal Murray  wrote:

tvb said:

Smearing is fine. It's a practical solution to an intractable problem. But
forcing everyone to implement it the exact same way misses the point. You
can't create a standard for your favorite set of time applications and then
try to force it upon everyone else's time applications.

I think that's misleading.  If you are going to smear, there are a lot of
problems that go away if everybody uses the same parameters.

Unless there are reasons to select one value over another, selecting one with
a coin flip is generally better than running incompatible implementations.

This is still early in the deployment cycle.  It may be appropriate to
experiment.  Unfortunately, leap seconds don't happen often enough to make
that an useful approach to gaining experience.

If it is still early in the development cycle, how can you say with
certainty that all smears are acceptable to all environments? As this
forum has discovered, the number of environments are quite large and
the assumptions are more varied than any one participant can fully
appreciate.
Indeed. Each of them have made judgments of how to do the smear based on 
their inventory of down-stream devices they hope to protect from the 
Leap Second. Each OS, each OS version, each DBMS, etc, may, or may not 
have, similar behavior. Note too the discussions of how they increment 
the smear so as to not upset some receiver's PPL. Now that they've 
deployed a smear and have a bazillion systems dependent on it they are 
going to be very reluctant to change what they're doing. Its all 
terribly indeterminate which is probably not what the financial system, 
government, justice system, and military wants to hear. You wonder if 
occasional system crashes aren't preferable to guaranteed inaccuracy.

-Brooks



Warner
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] A standard for leap second smearing

[Brooks Harris]

Hi Tom,

Seems to me this conversation is drifting back and forth between objectives.

It started out to explore if a common method of smear could be found for 
purposes as Google, AWS, and Bloomberg are using it. As I understand it, 
the whole point there is to "hide" the Leap Second from the very many 
consumers because its infeasible to anticipate the Leap Second behavior 
of every device. Some of those may be ancient. It's used as a practical 
matter for keeping the systems stable and the timestamps as accurate as 
possible under the circumstances where the consumers cannot be ungraded 
en mass. The point is exactly to fake out the consumers so they don't 
choke. I think its a very good idea that systems do it the same way.


The conversation then moved to exploring once again some more ideal 
method of handling Leap Seconds by somehow smearing within the consumer. 
That might be OK for some purposes, but many applications just can't 
accept or tolerate any frequency shifts in the timebase. That's why GPS 
and PTP ignore date accuracy for machine and process control. They have 
to because there's no reliable way to account for date and time with 
Leap Seconds. In the video broadcast industry a frequency shift like a 
smear would be catastrophic and a technique like that just can't be 
considered. Frequency stability is fundamental.


There are fundamental irreconcilable conflicts between some ideal Leap 
Second compensated timescale, even if we could agree on what that might 
be, and the traditional 86400 second day based timescales. Even if a 
good set of well defined and deterministic specifications for handling 
Leap Seconds emerged it will be necessary to continue to support the 
existing vast infrastructure of 86400-day devices.


Smear has become part of that infastructure, and refining it seems like 
a very good idea to me. Its encouraging that representatives of Google 
have joined the conversation. It seems like this thread should stay on 
that topic and explore what Google has learned about the practical 
application of smear in their environments, what their challenges and 
objectives are and more detail on how they've handled them so far.


-Brooks



On 2016-09-28 11:31 AM, Tom Van Baak wrote:

NTP is designed to disseminate the SI second and a UTC timestamp. If you want a 
completely different timescale (e.g., UT1, or some smeared variant of UTC) it seems like 
this could be part of NTP, not some opaque hack below or above NTP so as to "fake 
out" ancient or hardcoded assumptions of NTP.

Is it really easier and wiser to propose a universal layer of kernel 
timekeeping hacks than to change how NTP works or how NTP is configured or how 
UTC is defined?

/tvb

- Original Message -
From: "Stephen Colebourne" 
To: "Leap Second Discussion List" 
Sent: Wednesday, September 28, 2016 7:40 AM
Subject: Re: [LEAPSECS] A standard for leap second smearing



On 28 September 2016 at 14:39, Tony Finch  wrote:

Steve Summit  wrote:

Me, I'd very much rather *not* add this sort of thing to (say)
NTP, because NTP doesn't have a problem with leap seconds.

This does seem true - hacking ntp feels like the wrong solution.


Except that every leap second is screwed up by a large proportion of NTP
servers...

True. But there are far fewer ntp servers than installations of an OS
kernel. So, it should be a more tractable problem to fix.

Stephen
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Bloomberg announced its smear

[Brooks Harris]

Hmmm. You wonder why they chose 2000 seconds, which gives a nice round 
number of seconds for the duration: 2000/60=3.3... :-|


So, now there are at least 3 different smears in use by major providers 
to "hide" the Leap Second from downstream systems that might be upset by 
it. This produces indeterminate timestamps for the duration of their smears:


Two of them smear for 24 hours, 12 hours either side of the Leap Second 
midnight, but their increments don't match -


Look Before You Leap – The Coming Leap Second and AWS (Updated)
https://aws.amazon.com/blogs/aws/look-before-you-leap-the-coming-leap-second-and-aws/

Google Leap Smear 2015
https://mlichvar.fedorapeople.org/leap2015/google_smear.png

Now Bloomberg is smearing for 2000 seconds (or is it 2001 seconds?).

Bloomberg will smear over 2000 seconds after the leap.
https://data.bloomberglp.com/professional/sites/4/Bloomberg-Leap-Second_December-2016.pdf

Meantime Microsoft avoids a smear altogether by diverging from the 
common practice of introducing Leap Seconds on local timescales 
simultaneous with UTC and instead introducing the Leap Second at (the 
second before) midnight in each local zone. This results in integral 
second increments and a symmetrical distribution the Leap Second 
discontinuity across the local YMDhms representations.


The time on Microsoft Azure will be: Different by a second, everywhere
http://www.theregister.co.uk/2015/05/29/windows_azure_second_out_of_sync/

-Brooks


On 2016-09-23 10:45 AM, Steve Allen wrote:

Bloomberg will smear over 2000 seconds after the leap.
https://data.bloomberglp.com/professional/sites/4/Bloomberg-Leap-Second_December-2016.pdf

They are one of many cloud and financial operations who have,
ironically, decided that the non-precision timekeeping through the 1960s
(and of POSIX) is preferable to the precise time choice made by the CCIR.

--
Steve Allen  WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street   Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064   http://www.ucolick.org/~sla/   Hgt +250 m
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Bloomberg announced its smear

[Brooks Harris]

Hi Tony,

On 2016-09-26 09:52 AM, Tony Finch wrote:

Brooks Harris <bro...@edlmax.com> wrote:


Note too the discussions of how they increment the smear so as to
not upset some receiver's PPL.

Is anyone other than Google doing that? All the other smears I recall
(UTC-SLS, Amazon, Bloomberg) have been piecewise-linear. (It isn't clear
to me whether QTNet's smear was piecewise-linear or not.)
Not sure. This article on AWS's smear touches on it and has links to 
other references -


Look Before You Leap – The Coming Leap Second and AWS (Updated)
https://aws.amazon.com/blogs/aws/look-before-you-leap-the-coming-leap-second-and-aws/ 



In any event they are certainly not the same.

-Brooks


Tony.


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Bloomberg announced its smear

[Brooks Harris]

Hi Tom,

Thanks. I was part of that exchange. It drifted into theological debate 
about operating systems. Of course the many cultures of OSs and 
languages complicates the discussion, but it seems to me the timekeeping 
topic needs to rise above those crusades.


I was asking questions about Windows timekeeping. I've done quite a bit 
of experimentation about that. The short of it is Windows behave just 
like POSIX as far as I can tell, except its epoch, represented as struct 
FILETIME, is 1601-01-01T00:00:00 (UTC-like), which is, apparently the 
COBOL epoch (I didn't track down the references on that). It's an 
unsigned 64-bit counter with 100-nanosecond resolution. Its the 
timestamp of NTFS (DOS FAT32 is different, and I didn't go there).


typedef struct _FILETIME {
DWORD dwLowDateTime;
DWORD dwHighDateTime;
} FILETIME, *PFILETIME, *LPFILETIME;

I've implemented an experimental c++ version of SNTP, including calls to 
::SetSystemTime(). This behaves the same as the Windows desktop 
"Internet time" updates, as far as I can tell.


Meantime, POSIX time, as implemented by the MSVC c/c++ language and 
compiler, results in identical values (well, there are differences in 
resolution and format) as calls to the Windows system time functions. In 
fact, calls to POSIX functions like time() are wrappers to the ::system 
calls, such as ::GetLocalTime().


So, conceptually, and in the context of the Leap Second discussion, or, 
at least, the counting mechanisms used, there's really no difference 
between Windows time and POSIX time. Of course the implementations on 
various OSs and languages will differ.


-Brooks


On 2016-09-25 04:52 PM, Tom Van Baak wrote:

Brooks,


The Microsoft Azure approach of moving the leap second to local midnight has 
been discussed.
I suppose you mean at LEAPSECS? If so I've missed that and be interested in the 
reference.
I'd be interested in any other discussions of it as well.

There are several dozen posts in the archives starting May of 2105.
Start with this and keep clicking 'next':
https://pairlist6.pair.net/pipermail/leapsecs/2015-May/005920.html

/tvb

- Original Message -----
From: Brooks Harris
To:leapsecs@leapsecond.com  
Sent: Sunday, September 25, 2016 11:19 AM

Subject: Re: [LEAPSECS] Bloomberg announced its smear


Hi Gerry,
On 2016-09-25 07:58 AM, GERRY ASHTON wrote:

The Microsoft Azure approach of moving the leap second to local midnight has 
been discussed.
I suppose you mean at LEAPSECS? If so I've missed that and be interested in the 
reference. I'd be interested in any other discussions of it as well.

-Brooks

I don't know enough about Azure to say if it is acceptable in that context, but 
as a general approach, I object to midnight. National authorities in the US and 
Canada have decided the hour shift for daylight saving time should occur in the 
very early morning, but not at midnight; though I don't know the motivations 
for this choice, it's a good choice. Many deadlines occur at local midnight, 
and adherence to those deadlines is more and more often decided by computer 
timestamps. Thus, any time adjustments should not occur at local midnight. (Of 
course, this objection applies to places where UTC midnight is local midnight.


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Bloomberg announced its smear

[Brooks Harris]

Hi Gerry,
On 2016-09-25 07:58 AM, GERRY ASHTON wrote:


The Microsoft Azure approach of moving the leap second to local 
midnight has been discussed.


I suppose you mean at LEAPSECS? If so I've missed that and be interested 
in the reference. I'd be interested in any other discussions of it as well.


-Brooks


I don't know enough about Azure to say if it is acceptable in that 
context, but as a general approach, I object to midnight. National 
authorities in the US and Canada have decided the hour shift for 
daylight saving time should occur in the very early morning, but not 
at midnight; though I don't know the motivations for this choice, it's 
a good choice. Many deadlines occur at local midnight, and adherence 
to those deadlines is more and more often decided by computer 
timestamps. Thus, any time adjustments should not occur at local 
midnight. (Of course, this objection applies to places where UTC 
midnight is local midnight.




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Time Synchronization in Financial markets

[Brooks Harris]

On 2016-10-09 11:32 PM, John Sauter wrote:

On Sun, 2016-10-09 at 15:12 -0400, Brooks Harris wrote:


I took the lack of mention of leap seconds to mean that leap
seconds
ere not a problem.  The output of the NISTDC units is an
astonishingly
  accurate 1 pulse per second.  That feeds NTP, which handles leap
seconds using a table.  As long as the table is kept up to date,
everyone agrees on each second's name.

  Except the one to be called -MM-DDT23:59:60.

There are 86401 pegs in the (positive) Leap Second UTC day. There are
86400 holes in traditional timescales in which to put them. Something
has to to go missing - the mapping is indeterminate. Common practice
of introducing Leap Seconds on local timescales simultaneous with its
introduction at UTC places these indeterminate labels at different
time-of-day points along each local timescale. Non standardized and
politically driven Daylight Savings rules further complicates when
these indeterminate moments occur. Meantime there is no standardized
way to keep the Leap Second tables automatically updated to begin
with.

-Brooks

Not being a traditionalist myself, I don't feel that there is anything
wrong with 23:59:60 as a label for a particular second.  Thus, I don't
feel the need to map the 86,401 seconds of the last day of 2016 into
86,400 "holes", and therefore I do not suffer any indeterminacy.
 John Sauter (john_sau...@systemeyescomputerstore.com)
You are a fortunate individual. I continue to suffer from intermittent 
lags due to temporal radiation exposure.

-Brooks



___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Time Synchronization in Financial markets

[Brooks Harris]

Hi John,
On 2016-10-09 12:41 PM, John Sauter wrote:

On Sat, 2016-10-08 at 15:58 -0600, Warner Losh wrote:

On Sat, Oct 8, 2016 at 2:43 PM, Steve Allen  wrote:

On Fri 2016-10-07T11:48:25 -0600, Warner Losh hath writ:

Accurate, Traceable, and Verifiable Time Synchronization for
World
Financial Markets

http://nvlpubs.nist.gov/nistpubs/jres/121/jres.121.023.pdf

Market synchronization requirements today are 1s. However, in
August
2017 they become 50ms. Good thing normal market hours on the US
exchanges avoids the leap second...

Notably missing in this document is any mention of the term leap
second.
More surprising is no mention of TAI, despite the numerous
references
to the use of IEEE 1588 PTP for the timing systems.
It's like getting a tour map that describes the route but fails to
mention that along the way there's a bridge out.

Yes, it's like all the other systems I worked on that required
external UTC to be correct at all times, even when the GPS receiver
doesn't yet know the current number of leap seconds. I'll have to
pass
the leap second comment along to the author...

Warner

I took the lack of mention of leap seconds to mean that leap seconds
ere not a problem.  The output of the NISTDC units is an astonishingly
  accurate 1 pulse per second.  That feeds NTP, which handles leap
seconds using a table.  As long as the table is kept up to date,
everyone agrees on each second's name.

Except the one to be called -MM-DDT23:59:60.

There are 86401 pegs in the (positive) Leap Second UTC day. There are 
86400 holes in traditional timescales in which to put them. Something 
has to to go missing - the mapping is indeterminate. Common practice of 
introducing Leap Seconds on local timescales simultaneous with its 
introduction at UTC places these indeterminate labels at different 
time-of-day points along each local timescale. Non standardized and 
politically driven Daylight Savings rules further complicates when these 
indeterminate moments occur. Meantime there is no standardized way to 
keep the Leap Second tables automatically updated to begin with.


-Brooks

 John Sauter (john_sau...@systemeyescomputerstore.com)


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] The Fuzzball

[Brooks Harris]

We owe much to the pioneering work described in the article, and 
particularly to David Mills' contributions to computer timekeeping.


On 2017-01-09 09:57 PM, Brooks Harris wrote:

The Fuzzball
https://www.eecis.udel.edu/~mills/database/papers/fuzz.pdf

Ah. PDP 11 running RT11 (the RT stands for real-time, you know, and it 
was!). Bigger and much heavier than a breadbox it had a lot of power. 
Oh, wait, I mean it *used* a lot of power. And you could modify it 
with a soldering iron and hammer. :-)


-Brooks
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

[Brooks Harris]

As I said, Windows is huge and evolving, and Sever is different from 
regular Windows versions; be careful when mixing and matching versions. 
Some of these technotes are pretty recent, like 2014 or 2015. See -


How to configure an authoritative time server in Windows Server
https://support.microsoft.com/en-us/kb/816042

How the Windows Time Service Works
https://technet.microsoft.com/en-us/library/cc773013(WS.10).aspx

Support boundary to configure the Windows Time service for high-accuracy 
environments

https://support.microsoft.com/en-us/kb/939322

Domain Controller Roles
https://technet.microsoft.com/en-us/library/cc786438(v=ws.10).aspx

Windows Time Service Technical Reference
https://technet.microsoft.com/windows-server-docs/identity/ad-ds/get-started/windows-time-service/windows-time-service

Kerberos (protocol)
https://en.wikipedia.org/wiki/Kerberos_(protocol)
"Kerberos has strict time requirements, which means the clocks of the 
involved hosts must be synchronized within configured limits. The 
tickets have a time availability period and if the host clock is not 
synchronized with the Kerberos server clock, the authentication will fail."


-Brooks

On 2017-01-08 12:59 PM, Brooks Harris wrote:

On 2017-01-08 10:15 AM, Martin Burnicki wrote:

Brooks Harris wrote:

On 2017-01-06 11:52 AM, Martin Burnicki wrote:

- OS kernels with different features (Windows doesn't even know leap
seconds, AFAIK)



It is often repeated on LEAPSECS that "Windows doesn't even know leap
seconds". That's just not true. It knows very well about Leap 
Seconds in

the same way other systems do but it (typical desktop versions) is lazy
about when it updates - it doesn't attempt to update for Leap Seconds
until the particular system gets round to syncing to some NTP server
(defaulting to time.windows.com, but works perfectly well if set to
time.nist.gov, for example).

Many years ago I wrote a DOS TSR which could read the time from Meinberg
PCI cards (and ISA cards at that time), and adjusted the DOS time if
there was a significant difference.

So of course the DOS time was also adjusted after the plug-in card had
stepped its time due to a leap second.

So according to your argumentation even plain old DOS was aware of leap
seconds, wasn't it?

Yeah, I think so.

Really, none of DOS, Windows, or (pure) POSIX systems "know" about 
Leap Seconds except in so far as the reference counter (Windows 
FILETIME or POSIX time_t, (I can't remember what counter DOS relied 
on)) has been adjusted by the system in response to NTP queries. That 
adjustment gets reflected to YMDhms representation through calls to 
win::GetSystemTime() or POSIX::gmtime(). (Again, long time since I 
played with DOS, not sure the analogous calls)


By the way, DOS was essentially a real-time OS; you could hammer the 
interrupts however you liked. You don't want to do that in a 
multitasking event driven OS.





In Windows, FILETIME (an unsigned 64-bit value) is directly 
analogous to

POSIX time_t except it has a 1601-01-01 00:00:00 epoch. struct
SYSTEMTIME is analogous to POSIX struct tm ("broken down time" or
"YMDhms" representation). FileTimeToSystemTime() is analogous to POSIX
gmtime();

Like time_t, FILETIME is "bumped" when the system syncs to a NTP 
server.

Yes because the time adjustment software slews or steps the time.

Which Windows API call can be used to notify Windows that a leap second
is pending, so the Windows system time can account for it at the 
right time?
I am unaware of any part of Windows that is "aware" of Leap Seconds. 
There's no register somewhere that holds current TAI-UTC, announce, or 
history, I'm pretty sure, not at user-level access to the OS system 
calls, anyway.


(I'm hesitant to state this with great authority because Windows as a 
whole is just huge, and there are APIs on APIs developed and exposed 
over the years. I keep discovering yet another API that may expose 
deeper and deeper access to stuff. There might be something buried 
somewhere that can do this somehow. And Windows is always evolving, so 
something new might exist. Windows Server is something of a different 
animal than regular Windows PC versions, certainly with respect to its 
file system support, so there might be something different there 
regarding timekeeping, I don't know. I've never seen documentation of 
any such thing, though.)


Combinations of SetSystemTime() and SetSystemTimeAdjustment() can 
adjust the system clock. I've never tried to use them to tightly 
adjust system time. It would probably not be an easy project because 
monitoring accurate cause and effect would be tricky. I've played with 
SetSystemTimeAdjustment(), and it definitely changes things a bit, but 
never explored it carefully. But SetSystemTime() certainly works in 
the context of setting values obtained from NTP.


These functions adjust the "System timer" which is responsible for 
user-l

[LEAPSECS] The Fuzzball

[Brooks Harris]

The Fuzzball
https://www.eecis.udel.edu/~mills/database/papers/fuzz.pdf

Ah. PDP 11 running RT11 (the RT stands for real-time, you know, and it 
was!). Bigger and much heavier than a breadbox it had a lot of power. 
Oh, wait, I mean it *used* a lot of power. And you could modify it with 
a soldering iron and hammer. :-)


-Brooks
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] next leap second

[Brooks Harris]

On 2017-01-12 12:18 PM, Michael Shields via LEAPSECS wrote:

On Wed, Jan 11, 2017 at 5:03 PM, Warner Losh  wrote:

On Wed, Jan 11, 2017 at 3:28 PM, Zefram  wrote:

It would be nice to have more sophisticated projections from IERS more
than a year ahead.  It would particularly help in evaluating the proposals
that have been made involving scheduling leap seconds further ahead.

Especially if they had error bars that reflect the current confidence
levels, perhaps tested on historic data.

It might also be helpful if we understood better how these models are
used to decide when to announce leap seconds.
As I understand it, it's pretty complicated. IERS is the top node in a 
hierarchy of entities; there are many contributing organizations 
including the participating observatories and interaction with BIPM. The 
IERS conventions guide the procedures, and those are large and 
complicated documents. It's a pretty big administrative and technical 
apparatus. It would be nice to understand it better, but the bottom line 
for practical timekeeping discussions seems to be the IERS products.


Maybe someone can inform us better?

-Brooks

I don't know currently
what criteria the IERS uses, except the overall parameters of keeping
|UT1-UTC| < 0.9 s and preferring to have leap seconds in June or
December instead of other months.

For example, here's Bulletin A from 2016-06-30:

https://datacenter.iers.org/eop/-/somos/5Rgv/getTX/6/bulletina-xxix-026.txt

2016-12-31 (MJD 57753): -0.45079 s
2017-06-30 (MJD 57934): -0.73759 s

You might have expected either of these days to have leap seconds.
The next week, Bulletin C Number 52 announced a leap second for
2016-12-31.  The actual value of UT1-UTC on that day was about
-0.407858 s.

The predictions looked similar on 2014-06-26:

https://datacenter.iers.org/eop/-/somos/5Rgv/getTX/6/bulletina-xxvii-026.txt

2014-12-31 (MJD 57022): -0.46583 s
2015-06-26 (MJD 57199): -0.67258 s

Again, either December 2014 or June 2015 could have had leap seconds.
But in this case the leap second was deferred.  It happened on
2015-06-30, when UT1-UTC was -0.6760362 s
(https://datacenter.iers.org/eop/-/somos/5Rgv/getTX/207/bulletinb-330.txt).
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] next leap second

[Brooks Harris]

IERS Technical Note No. 36
IERS Conventions (2010)
ftp://tai.bipm.org/iers/conv2010/tn36.pdf

-Brooks

On 2017-01-12 01:08 PM, Brooks Harris wrote:

On 2017-01-12 12:18 PM, Michael Shields via LEAPSECS wrote:

On Wed, Jan 11, 2017 at 5:03 PM, Warner Losh <i...@bsdimp.com> wrote:

On Wed, Jan 11, 2017 at 3:28 PM, Zefram <zef...@fysh.org> wrote:

It would be nice to have more sophisticated projections from IERS more
than a year ahead.  It would particularly help in evaluating the 
proposals

that have been made involving scheduling leap seconds further ahead.

Especially if they had error bars that reflect the current confidence
levels, perhaps tested on historic data.

It might also be helpful if we understood better how these models are
used to decide when to announce leap seconds.
As I understand it, it's pretty complicated. IERS is the top node in a 
hierarchy of entities; there are many contributing organizations 
including the participating observatories and interaction with BIPM. 
The IERS conventions guide the procedures, and those are large and 
complicated documents. It's a pretty big administrative and technical 
apparatus. It would be nice to understand it better, but the bottom 
line for practical timekeeping discussions seems to be the IERS products.


Maybe someone can inform us better?

-Brooks

I don't know currently
what criteria the IERS uses, except the overall parameters of keeping
|UT1-UTC| < 0.9 s and preferring to have leap seconds in June or
December instead of other months.

For example, here's Bulletin A from 2016-06-30:

https://datacenter.iers.org/eop/-/somos/5Rgv/getTX/6/bulletina-xxix-026.txt 



2016-12-31 (MJD 57753): -0.45079 s
2017-06-30 (MJD 57934): -0.73759 s

You might have expected either of these days to have leap seconds.
The next week, Bulletin C Number 52 announced a leap second for
2016-12-31.  The actual value of UT1-UTC on that day was about
-0.407858 s.

The predictions looked similar on 2014-06-26:

https://datacenter.iers.org/eop/-/somos/5Rgv/getTX/6/bulletina-xxvii-026.txt 



2014-12-31 (MJD 57022): -0.46583 s
2015-06-26 (MJD 57199): -0.67258 s

Again, either December 2014 or June 2015 could have had leap seconds.
But in this case the leap second was deferred.  It happened on
2015-06-30, when UT1-UTC was -0.6760362 s
(https://datacenter.iers.org/eop/-/somos/5Rgv/getTX/207/bulletinb-330.txt). 


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] private smear goes public

[Brooks Harris]

Hi Stephen,
On 2016-12-01 02:49 AM, Stephen Colebourne wrote:

More details on the developer site:
https://developers.google.com/time/

Notably this page:
https://developers.google.com/time/smear

which include "Our proposed standard smear" - "We would like to
propose to the community, as the best practice for leap seconds in the
future, a 24-hour linear smear from noon to noon UTC"

Hip hip hooray! De facto standards for the win!

Stephen

Ah, this is good. I'd missed that page yesterday.

I might suggest you good go a little further.

You say "Each second of time marked by Google's servers will be about 
13.9 μs longer than an SI second. "


Some developers may probably need to know exactly, or as exactly as 
possible, the ratio.


If I've got this right:

20 hours = 20 * 60 * 60 = 72000 seconds
Plus the Leap Second = 72001 second
So the ratio is 72001 / 72000 = 1.13889 (rounded to 10-9th 
precision, nanoseconds)

This a repeating decimal number which may be denoted 1.13(8).
Applications should be careful to provide adequate precision for the 
purpose.


-Brooks









On 30 November 2016 at 21:05, Tom Van Baak  wrote:

I'm surprised no one has posted this news yet:

"Making every (leap) second count with our new public NTP servers"
https://cloudplatform.googleblog.com/2016/11/making-every-leap-second-count-with-our-new-public-NTP-servers.html

/tvb

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] private smear goes public

[Brooks Harris]

Hi Stephen,

On 2016-12-01 01:08 PM, Stephen Scott wrote:

Hello Brooks, Stephen;

What's all this discussion about precision?

Merely about the math of their smear method.


The smear has tossed the precision of the second SI out the window.
This is totally unacceptable for an application that requires a 
precise and stable frequency reference (telecommunications and 
broadcast for example).
Yes, of course, but the whole purpose of the smear is to hide the Leap 
Second from the downstream 86400-second-day systems, especially 
operating systems, that may not be prepared to cope with the Leap 
Second. As I understand it, it compromises accuracy for reliability, 
buts that the best solution to avoiding potential wide-spread problems.


Further, this is not the only smear algorithm.
A proliferation of smears could be the best reason for getting rid of 
the leap second.
As I read it I think Google's intention is to publish their method and 
algorithm in the hopes others may follow it. It would be better if 
everybody did it the same way, but it will remain to be seen if others 
will choose to follow the example.


-Brooks



The time community is not monolithic and there are different 
requirements of users.

No single approach is likely to satisfy all.
There is a requirement for a minimal set of standardized approaches.

-Stephen


On 2016-12-01 12:39, Brooks Harris wrote:

Hi Stephen,
On 2016-12-01 02:49 AM, Stephen Colebourne wrote:

More details on the developer site:
https://developers.google.com/time/

Notably this page:
https://developers.google.com/time/smear

which include "Our proposed standard smear" - "We would like to
propose to the community, as the best practice for leap seconds in the
future, a 24-hour linear smear from noon to noon UTC"

Hip hip hooray! De facto standards for the win!

Stephen

Ah, this is good. I'd missed that page yesterday.

I might suggest you good go a little further.

You say "Each second of time marked by Google's servers will be about 
13.9 μs longer than an SI second. "


Some developers may probably need to know exactly, or as exactly as 
possible, the ratio.


If I've got this right:

20 hours = 20 * 60 * 60 = 72000 seconds
Plus the Leap Second = 72001 second
So the ratio is 72001 / 72000 = 1.13889 (rounded to 10-9th 
precision, nanoseconds)

This a repeating decimal number which may be denoted 1.13(8).
Applications should be careful to provide adequate precision for the 
purpose.


-Brooks









On 30 November 2016 at 21:05, Tom Van Baak <t...@leapsecond.com> wrote:

I'm surprised no one has posted this news yet:

"Making every (leap) second count with our new public NTP servers"
https://cloudplatform.googleblog.com/2016/11/making-every-leap-second-count-with-our-new-public-NTP-servers.html 



/tvb

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] private smear goes public

[Brooks Harris]

On 2016-12-01 06:28 PM, Stephen Colebourne wrote:

On 1 December 2016 at 19:45, Brooks Harris <bro...@edlmax.com> wrote:

As I read it I think Google's intention is to publish their method and
algorithm in the hopes others may follow it. It would be better if everybody
did it the same way, but it will remain to be seen if others will choose to
follow the example.

The page reads clearly enough to me that:

- Google will leap over 20 hours this time because it is too late to
change their plans
- They plan to leap over 24 hours next time to match Amazon and others
- The propose an informal "standard" of 24 hours leaps henceforth

If all the big IT players agree on a 24 hour leap, 12 hours either
side of midnight UTC, then we have all moved a step forward. Even more
so if they write up the approach as a formal standard.

That's all good, I think.


The next issue is that there are then two types of NTP server -
smeared and non-smeared - and no way to tell the difference. Call me
naive, but that seems like a perfectly soluble problem, either within
NTP or external to it.
One quick thought - the smeared NTP servers could be distinguished by 
their DNS names, something along the lines of "time.smear20.google.com" 
or "time.smear24.google.com?


For the record, I think that both leap-smeared and leap-accurate
broadcast time have value, but it should be easily possible to tell
which is being received. I also desperately want there to be a name
for the proposed informal standard, so we can all talk about it.

Hmmm. I agree, a name would be helpful.

"Smear" seems to have taken hold, if not technically exact, at least 
intuitively descriptive. I don't know what a technically proper term for 
that would be.


Above I implied names that signaled the smear's span - "smear20", 
"smear24". There might be other characteristics to incorporate in a name?


-Brooks



Stephen
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] private smear goes public

[Brooks Harris]

Hi Warner,
On 2016-12-01 08:02 PM, Warner Losh wrote:

On Thu, Dec 1, 2016 at 4:28 PM, Stephen Colebourne <scolebou...@joda.org> wrote:

On 1 December 2016 at 19:45, Brooks Harris <bro...@edlmax.com> wrote:

As I read it I think Google's intention is to publish their method and
algorithm in the hopes others may follow it. It would be better if everybody
did it the same way, but it will remain to be seen if others will choose to
follow the example.

The page reads clearly enough to me that:

- Google will leap over 20 hours this time because it is too late to
change their plans
- They plan to leap over 24 hours next time to match Amazon and others
- The propose an informal "standard" of 24 hours leaps henceforth

If all the big IT players agree on a 24 hour leap, 12 hours either
side of midnight UTC, then we have all moved a step forward. Even more
so if they write up the approach as a formal standard.

The next issue is that there are then two types of NTP server -
smeared and non-smeared - and no way to tell the difference. Call me
naive, but that seems like a perfectly soluble problem, either within
NTP or external to it.

For the record, I think that both leap-smeared and leap-accurate
broadcast time have value, but it should be easily possible to tell
which is being received. I also desperately want there to be a name
for the proposed informal standard, so we can all talk about it.

I find the two different types of time amble evidence that leap
seconds are evil and must die. Nobody knows what to do with them. Few
get it right so we have to resort to tricks to pretend they aren't
there. And people that care wind up disappointed that more things
don't get them right. Clearly the bastard stepchild of time that
should be relegated to the dustbin of history.
I'm sure you know I'm on the other side of that opinion; that UTC with 
Leap Seconds is a very good, even brilliant, solution to the 
inconvenient fact of the Earth's wobbly rotation to preserve the age old 
tradition of timekeeping by the sun. This in the same way Gregorian 
calendar 'solved' the length of the year.


But, regardless of our opinions, Leap Seconds are here to stay until at 
least 2023 and probably much longer. So, "smear" is with us to protect 
the 86400-second-day systems. There's no avoiding this, really, because 
those systems have no hole into which the 86401th peg can be put. And, I 
might add, who ever tested the systems end-to-end for a negative Leap 
Second?


-Brooks




Warner
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] private smear goes public

[Brooks Harris]

On 2016-11-30 10:23 PM, Michael Shields via LEAPSECS wrote:

On Wed, Nov 30, 2016 at 7:06 PM, Brooks Harris <bro...@edlmax.com> wrote:

One wishes announments like this were a bit more accurate. They say "...
we'll run the clocks 0.0014% slower across the ten hours before and ten
hours after the leap second ...", but I think it must be closer to
0.0013 percent. I wonder what precision they use?

It would, of course, take an infinite number of decimal digits to
represent the actual ratio.

Yes. An ever irritating fact of life.

The calculations are done at nanosecond
precision.

OK, makes sense. Thanks.
-Brooks


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] private smear goes public

[Brooks Harris]

Hi Tom,

Sure enough, it's there. I've got an SNTP client I built for Windows I 
use for simple investigations. It connects to time.google.com just fine. 
(And, by the way, shows a much shorter round-trip-delay than nist ntp 
servers I've used).


One wishes announments like this were a bit more accurate. They say "... 
we'll run the clocks 0.0014% slower across the ten hours before and ten 
hours after the leap second ...", but I think it must be closer to 
0.0013 percent. I wonder what precision they use?


-Brooks


On 2016-11-30 04:05 PM, Tom Van Baak wrote:

I'm surprised no one has posted this news yet:
"Making every (leap) second count with our new public NTP servers"
https://cloudplatform.googleblog.com/2016/11/making-every-leap-second-count-with-our-new-public-NTP-servers.html
/tvb


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] private smear goes public

[Brooks Harris]

Thanks Tony,

On 2016-12-02 10:03 AM, Tony Finch wrote:

Brooks Harris <bro...@edlmax.com> wrote:


Can you explain that copyright issue further? I was under the impression
Bulletin C and related from IERS were public.

There was a discussion of this issue on the tz list in February:
http://mm.icann.org/pipermail/tz/2016-February/023171.html

Tony.


I see the discussion. On quick review, as I understand it, IERS Bulletin 
C is the single most official Leap Second announcement document -


Bulletin C 52
https://hpiers.obspm.fr/eoppc/bul/bulc/bulletinc.52

It does not have any copyright claims on it I can identify. Not do the 
other related files, like 
https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat.


Seems to me any copyright claim would defeat the IERS purposes. Seems to 
me if there were such it would have to be stated in Bulletin C itself.


Where did anyone learn there is some copyright issue with IERS documents?

-Brooks



___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] private smear goes public

[Brooks Harris]

On 2016-12-02 12:57 AM, Warner Losh wrote:

On Thu, Dec 1, 2016 at 6:49 PM, Brooks Harris <bro...@edlmax.com> wrote:

Hi Warner,

On 2016-12-01 08:02 PM, Warner Losh wrote:

On Thu, Dec 1, 2016 at 4:28 PM, Stephen Colebourne <scolebou...@joda.org>
wrote:

On 1 December 2016 at 19:45, Brooks Harris <bro...@edlmax.com> wrote:

As I read it I think Google's intention is to publish their method and
algorithm in the hopes others may follow it. It would be better if
everybody
did it the same way, but it will remain to be seen if others will choose
to
follow the example.

The page reads clearly enough to me that:

- Google will leap over 20 hours this time because it is too late to
change their plans
- They plan to leap over 24 hours next time to match Amazon and others
- The propose an informal "standard" of 24 hours leaps henceforth

If all the big IT players agree on a 24 hour leap, 12 hours either
side of midnight UTC, then we have all moved a step forward. Even more
so if they write up the approach as a formal standard.

The next issue is that there are then two types of NTP server -
smeared and non-smeared - and no way to tell the difference. Call me
naive, but that seems like a perfectly soluble problem, either within
NTP or external to it.

For the record, I think that both leap-smeared and leap-accurate
broadcast time have value, but it should be easily possible to tell
which is being received. I also desperately want there to be a name
for the proposed informal standard, so we can all talk about it.

I find the two different types of time amble evidence that leap
seconds are evil and must die. Nobody knows what to do with them. Few
get it right so we have to resort to tricks to pretend they aren't
there. And people that care wind up disappointed that more things
don't get them right. Clearly the bastard stepchild of time that
should be relegated to the dustbin of history.

I'm sure you know I'm on the other side of that opinion; that UTC with Leap
Seconds is a very good, even brilliant, solution to the inconvenient fact of
the Earth's wobbly rotation to preserve the age old tradition of timekeeping
by the sun. This in the same way Gregorian calendar 'solved' the length of
the year.

If it was solved in the same way that the Gregorian Calendar solved
the leap year problem, everybody would get it right. Leap days aren't
a big deal because there's a tiny bit of math that I can do and get it
right every time. I can get the math wrong and still be right for the
next 84 years if I don't know all the rules. The Gregorian Calendar,
though a bit complex, is 100% predictable. I know there will be a Feb
29, 2020, and there won't be a Feb 29, 2021. And I don't need an
internet connection or other data stream to know that.
Sure. I meant only that Gregorian makes an adjustment to the calendar 
counting scheme to keep it aligned to the sun and moon, while Leap 
Seconds makes a much smaller, irregular, adjustment for similar reasons.


Leap seconds are unlike this because they are irregular. They come and
go at the when of the earth's rotation and a bureaucrat's whim.
Well, it seems much more organized than a "whim" to me. An awful lot of 
work by many organizations goes into the IERS's decisions about Leap 
Seconds.

They
aren't regular. You have to know and be in the loop or you'll get them
wrong. There's no formula to look up, no regular rule. There's no math
that will save you. You have to wait for people to look out the window
and hold their thumb in the air and say "it's time". That's another
problem with leap seconds: they are irregular and there's no standard
way to get the leap second info reliably
Oh yes. This seems like an obvious missing link to me. Its been 
discussed here many times.

(though there are sources of
data on the internet that are changing that if you are connected.
From one point of view, too many. And they are not yet uniformly 
formatted nor officially backed up by IERS.


It seems to me IETF RFC 7808, Time Zone Data Distribution Service 
https://tools.ietf.org/html/rfc7808 is the closest thing to a promising 
standard, but its not yet been implemented as a service I know of. It 
seems to hold promise, but there are probably many steps toward formal 
standardization needed to assure the quality of the data before its 
really "official" and uniformly deployed.



Since they are so irregular, nobody gets them right. They aren't
generally included in discussions about time like leap days are. They
are this weird little thing at the edge of UTC that makes it necessary
to have the slewing solutions. Too few people know about how to cope
with them, and the computer standards pretend they don't exist.
Right. Its going to be a very long migration path toward truly Leap 
Second compatible applications. Today there's no coherent plan to 
accomplish that end-to-end.

Unlike
leap days, this is far from a solved problem.

Yup. That's why LEAPSE

Re: [LEAPSECS] private smear goes public

[Brooks Harris]

Hi Tony,

On 2016-12-02 08:43 AM, Tony Finch wrote:

Poul-Henning Kamp  wrote:

I don't know what the effective latency is from IERS -> TZdata -> distros ->
releases -> users -> computers, but 6 months is only going to be enough
if everybody pays maximum attention *EVERY* *BLOODY* *TIME*.

The cascade actually goes IERS -> NIST -> tz because the NIST leap seconds
announcement is public domain whereas the IERS announcement has an unclear
copyright status.
Can you explain that copyright issue further? I was under the impression 
Bulletin C and related from IERS were public.

-Brooks

And since leap seconds are rather peripheral to the tz
database's purpose, they aren't pushed out amazingly swiftly.

http://mm.icann.org/pipermail/tz/2016-July/023867.html
http://mm.icann.org/pipermail/tz/2016-August/023914.html

Tony.


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Time math libraries, UTC to TAI

[Brooks Harris]

On 2017-01-04 09:15 PM, Steve Summit wrote:

Martin Burnicki wrote:

If we don't look only at the kernel and ntpd, but also consider PTP,
then there's still the question if if wouldn't be better to let the
kernel time run on TAI, and derive true and/or smeared UTC from it.

Right.  At first when I was trying to implement CLOCK_UTC, I
lumped it in with the problem of reworking the kernel's internal
clock, but actually, they're separate problems.  Although I
*have* reworked the kernel's internal clock (Linux calls it
'xtime'), it's expensive, and I'm now considering it among other
options, of which there are at least three:

1. Have xtime keep true UTC, as I've been doing so far.  This was
always my first choice, but it ends up being majorly invasive,
and I fear the Linux kernel developers will lynch me if I so
much as mention it.

2. Have xtime keep TAI.  This has the advantage that it's not at
all wrong or kludgey to represent TAI as a simple count of
seconds since the epoch, which of course xtime already is.
The objection, as mentioned here pretty regularly, is that if
you want to be able to set the clock from UTC, and deliver
UTC, you always need to know TAI-UTC, so if you don't have it
(if you're not on the net, or if you don't faithfully receive
it early enough during boot) you're sunk.  But I'm now
thinking that the work involved in assuming TAI-UTC=0 in that
case (and remembering that we can't, for example, return
success if someone asks for clock_gettime(CLOCK_TAI), and
remembering to fiddle things if we learn TAI-UTC later) may
end up being less than the work involved in #1.

3. Keep xtime just about the way it is, augmented with a
well-defined leap-second flag (along the lines of the TIME_OOP
flag returned by adjtimex) so that CLOCK_UTC can still be
derived from it with full accuracy.

Number 1 was my strong preference at first, because I very much
wanted a kernel that kept "true UTC" internally, with no kludges
or circumlocutions, and derived everything else from it as
necessary.  But the implementation cost to achieve that wish is
turning out to be very high, so #2 (and even the philosophically
ghastly but nicely expedient #3) are starting to look more
attractive.
It seems to me infeasible to alter the basic behavior of time_t because 
it effects every aspect of the operating system, including the file 
system, and all the applications that rely on it, not to mention being 
non-compliant with POSIX time as it stands. It must continue to behave 
as expected, even if its not ideal where UTC is concerned. POSIX time 
and 86400-second-day systems (including Windows time) will never exactly 
match UTC at the Leap Second and we'll have to live with that partial 
inaccuracy for a long time.


But a second, parallel, time system (call it POSIX Time2) could 
implement a fixed-epoch timer (call it time2_t) and a 
Leap-Second-accurate API that would yield YMDhms representation 
including 23:59:60, call them, for examples, gmtime2() and mktime2().


With that, those applications that needed it could use the POSIX Time2 
API, and everybody else would be none the wiser. It would also define 
the mapping between legacy POSIX and the UTC-accurate POSIX Time2. 
Eventually, maybe the file system timestamps could be augmented with 
flags to mark Leap Second instances and local time parameters.


-Brooks


___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Time math libraries, UTC to TAI

[Brooks Harris]

On 2017-01-06 02:56 PM, Warner Losh wrote:

Keep in mind that leap seconds have a short shelf life. Over the next
1000 years, it's projected TAI - UT will grow to about an hour
(2500-4500 if I'm reading
https://www.ucolick.org/~sla/leapsecs/deltat.html right).
I dare say everybody on LEAPSECS have shorter shelve lives than any of 
the TAI-UTC viability guesstimates. It will have to be adjusted 
sometime, no doubt, but we can't know how yet. So lets find a counting 
solution that has range in excess of current guesses and engineers of 
the future can decide what to do about it then.

-Brooks


In two
thousand it will be about 4 hours due to quadratic acceleration.
That's ~10k seconds in 1k years, or about one per month. The current
UTC spec will run out of steam long before then, as it defines only 4
times to insert leap seconds (well, 4 preferred times, any month can
be victim). Needing 12 per year means we're driving at about 1s/month
which means that keeping DUT1 to < 0.9 will be a challenge due to
seasonal variation and such. The Nyquist limit suggests that we'll run
out of steam when we hit one every 6 months, which would be about
~1200 years from now (give or take a few hundred, there's a lot of
uncertainty in the long term rate). Some new means of synchronization
must be found, the only real question is when. Well before that date,
letters from BIPM/IERS will cease to cut it (I'm in the camp that says
we're already past that date: no reliable[*] means to get leap seconds
exists today from authoritative sources).

Warner

[*] By this I mean some non-forgeable, authoritatively signed by
BIPM/IERS table of leap seconds, automatically updated and an
official, guaranteed service of the agency.

On Fri, Jan 6, 2017 at 12:29 PM, GERRY ASHTON <ashto...@comcast.net> wrote:

The Gregorian calendar and UTC with leap seconds are in harmony; the customary 
change-of-day time with the Gregorian calendar is midnight, and the methods used to 
establish midnight throughout most of the time the Gregorian calendar has been in use did 
not approach accuracy of tens of seconds. It is TAI or other 86,000-SI-seconds-per-day 
time scales that will not be in harmony with the Gregorian calendar in hundreds or 
thousands of years when the difference between mean solar time and 
86,000-SI-seconds-per-day time scales becomes appreciable ("appreciable" 
literally being a religious issue).


On January 6, 2017 at 5:50 PM Brooks Harris <bro...@edlmax.com> wrote:


On 2017-01-05 09:33 PM, Steve Summit wrote:

Brooks Harris wrote:

It seems to me infeasible to alter the basic behavior of time_t
because it effects every aspect of the operating system,

Absolutely.  Posix time_t is untouchable, and here to stay.


POSIX time and 86400-second-day systems (including Windows time) will
never exactly  match UTC at the Leap Second and we'll have to live
with that partial inaccuracy for a long time.

Right.  (But I don't know if people will find the inevitable
discrepancies between time_t and "Time2" acceptable.)

That's been at the heart of the "eliminate Leap Seconds debate", right?
Two camps, basically. But given both UTC with Leap Seconds and Gregorian
as inevitable conventional circumstances its no longer a question of
acceptable or not. It is what it is, so lets agree how best to support
the two with the least inaccuracy, least complexity, and least
disruption to existing systems. It can't be perfect; the two just do
not, and will not, match. There's not enough holes in Gregarian to
accommodate the Leap Second pegs.


But a second, parallel, time system (call it POSIX Time2) could
implement a fixed-epoch timer (call it time2_t) and a
Leap-Second-accurate API that would yield YMDhms representation
including 23:59:60, call them, for examples, gmtime2() and mktime2().

That's essentially what clock_gettime(CLOCK_UTC) gets you.
A struct timespec fetched with clock_gettime(CLOCK_UTC) is your
"POSIX Time2".  I have implemented gmtime_ts_r() and mktime_ts()
which operate on struct timespec, and do the right thing with :60.

Ah good.

What source are you using for the Leap Seconds? Tz Database?


With that, those applications that needed it could use the POSIX Time2
API, and everybody else would be none the wiser. It would also define
the mapping between legacy POSIX and the UTC-accurate POSIX Time2.

That's exactly my intent, and I have it all working on my test
system today.  Just one or two more bugfixes and I should be
ready to post it!  (I've been saying for the past several months.)

Its a harder problem than it appears, as those of us who've got our
fingers dirty with the implementation details can attest. Going at it
directly in the OS takes guts :-)

Eventually, maybe the file system timestamps could be augmented with
flags to mark Leap Second instances and local time parameters.

I'm not ready to think about the filesystem yet (beyond thinking
that leapsecond-aware filesyst

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

[Brooks Harris]

On 2017-01-06 11:33 AM, Martin Burnicki wrote:

Brooks Harris wrote:

On 2017-01-05 05:56 AM, Tony Finch wrote:

Martin Burnicki<martin.burni...@burnicki.net>  wrote:

Please note that NTP servers not necessarily need to be providers for
leap second files. There are some well known sites which provide this
file, and the NTP software package from ntp.org comes with a script
which can be used to update the file automatically.

I was thinking more that an NTP client or server would use its
leapseconds
file for validating LI bits from servers and for determining when they
should leap.

My thinking is that routine software patching and security updates happen
often enough that maybe NTP can get leap second more reliably out-of-band
instead of using in-band leap indicators from upstream servers.
Lower-stratum devices could use their own leap second information to
correct for operational or implementation errors upstream.


The potential approach with tzdist or special DNS allowed for a
distributed system, where the special DNS can only provide leap second
warning and the current TAI offset, while tzdist also provides the leap
second history, and a way to update time zone rules, so it could be
generally used to keep also conversion to local time correct.

Oh, I forgot about the DNS publication scheme. That would also help a lot
if it were implemented. And maybe better than relying on sufficiently
frequent software updates.

So, thing is, since 1972, no common and official way to automatically
obtain the Leap Seconds information has been adopted. Its an obvious
missing link, missing for 4 decades! I'd find this just incredible
except I've now come accept this sort of frustration where timekeeping
is concerned. This has been discussed many times on LEAPSECS.

Hm, I think there was no such requirement when NTP was introduced. Folks
were happy that they could at all forward leap second announcements,
which was sufficient then.

The leap second file was introduced by Judah Levine in 2000, AFAIK, see:
http://tycho.usno.navy.mil/ptti/2000papers/paper34.pdf

This was probably because it became more important to know the history
of leap seconds, and thus the TAI offset.
Right, that's where I say its incredible nothing was done since 1972. 
The Leap Second history is fundamental, and it seems to me an obvious 
missing link. How could it have gone ignored all this time?


I guess it comes from a point of view of distributing "now". That was 
always the first objective, to simply drive a clock - from there, humans 
could read the calendar and clock and apply their knowledge to calculate 
appointments - that was good enough, and the means to do more 
automatically didn't really exist. But that ignores the modern needs of 
applications to calculate durations, a fundamental requirement.


I've always seen the need to be able to accurately represent the entire 
UTC timescale (since UTC1972), both as seconds-since-UTC1972 and as 
YMDhms(UTC). This provides accurate historical timestamps (back to 
UTC1972) and so, durations. It also provides prediction, or scheduling, 
out to the next announced Leap Second or expiration.


It also provides means of testing algorithms against known values in 
development. The "corner cases", like Leap Seconds and DST shifts are 
the tricky bits, and you only know the values for the past. You haven't 
solved the general problem if you can't represent the entire timescale. 
Its straight forward *if* you have the Leap Seconds table. Oh, and if 
everybody is treating it exactly the same way.


Helping develop a clear and official way to get the Leap Second table 
should be a long term objective, I think.




Ntpd's "autokey" feature was
(mis-)used to be able to pass the TAI offset down to clients.

As I wrote in another email, when autokey is obsoleted by NTS then
eventually another new NTP extension field is required to be able to do
this via the NTP protocol.

Anyway, it's quite a number of years.


Ideally there would be one, and only one, TAI-UTC table, in some very
well specified form, residing somewhere in cyberspace, administered and
maintained by official rules and regulations by the IERS. There then
could be many API's via many technologies to access the information.

Agreed.


Today, there are many ways to get it, but they are all in different
forms, not always so well specified, and all require some human
intervention or oversight somewhere between the IERS announcements and
the distribution. None of them are particularly "fast", imposing too
much overhead on the receiver in some circumstances. And "many ways to
get it" does not inspire confidence that each implementation will get
everything the same.

I like the DNS publication scheme because you could imagine that IANA
could take responsibility for maintaining it, especially if there were
an official way to keep it automatically updated from a hypothetical
official IERS so

Re: [LEAPSECS] Time math libraries, UTC to TAI

[Brooks Harris]

On 2016-12-28 04:16 PM, Steve Allen wrote:

On Wed 2016-12-28T16:00:17 -0500, Brooks Harris hath writ:

I don't think so. This is POSIX so-called "1970-01-01 00:00:00 UTC"
not 1588/PTP. 1588/PTP epoch is 10s earlier.

At 1970-01-01 the difference TAI - UTC(BIH) was 8.82 SI seconds.
I trust you're calculations, and your stating it as "TAI-UTC(BIH)" makes 
it clear its not UTC(NIST) or some other UTC, and that's good. But, as 
you point out below,  ".. all of this is pedantic and moot for any 
currently operational system because it was not operational then".


The "rubber band era", the period of development of TAI and UTC from 
approximately 1960 to 1971 which led to the crucial TAI-to-UTC 
calibration point of 1972-01-01 00:00:10 (TAI) = 1972-01-01 00:00:00 
(UTC), may be seen as an interesting  but obsolete history which is now 
irrelevant to consideration of practical timekeeping.


I've been in many discussions of this issue and struggled with it 
myself. If you engage the UTC specifications starting with ITU-R Rec 460 
and attempt to understand the origins and TAI-UTC values you may first 
find -


BIPM Annual Report on Time Activities 
(http://www.bipm.org/en/bipm/tai/annual-report.html)

Table 1. Relative frequency offsets and step adjustments of UTC...
Table 2. Relationship between TAI and UTC...

Those tables list the frequency and non-integral seconds adjustments 
prior to 1972. This leads one to believe these values are relevant to 
understanding and implementing UTC. But the documentation is complex and 
unclear, leading to further research to discover or confirm your 
understanding.


There is a hole in the data of these tables; Rec 460 tells us the origin 
of TAI is "1 January 1958" but the first TAI-UTC value listed in the 
tables is in 1961 - what happened between 1958 and 1961? What does "1 
January 1958" mean; 1958-01-01 00:00:00 (TAI) or 1958-01-01 00:00:00 
(UTC)? Wait, did UTC exist in 1958? Why 1958? Eventually you might 
discover that "1 January 1958" was put in place retroactively in 1971 
(Rec 460 actually tells us so, but the history of it in the literature 
is convoluted). OK, but what is the TAI-UTC offset at 1958-01-01? Turns 
out, obscurely, zero. Hmmm. The TAI-UTC offset is exactly 10 seconds at 
TAI1972 = UTC1972. So how, exactly, should we distribute the TAI-UTC 
values across that 1958-to1972 period? And if the atomic time frequency 
itself was being changed how should we reconcile this with a system that 
has a stable frequency?


Many of us have been led down this path, and we've probably found 
Steve's excellent and extensive documentation about timescales.


In the end the only sensible thing to do is ignore these obsolete facts 
and establish a proleptic integral-second timescale. That's exactly what 
NTP does, and many POSIX-based systems. The TAI-UTC values published by 
IERS, such as 
(https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat), show 
no TAI-UTC values prior to TAI1972 = UTC1972.


Yet the idea that a timescale must honor these historical facts 
persists. I've come to see this whole topic of pre-1972 TAI-UTC values 
as a trap, a trip down a rabbit hole.



The first version of IEEE 1588 was not entirely consistent with its
text and appendix information, so it was not clear whether that time
scale was supposed to be TAI or TAI - 10.
The second version of IEEE 1588 clarified that the intent is TAI.
I've been involved in lengthy discussions about the PTP "epoch", and 
this has been entangled with the difficulties of defining the TAI-to-UTC 
relationship prior to 1972.


[By the way, IEEE 1588 defines "epoch" as "3.1.9 epoch: The origin of a 
timescale.". This is arguably, perhaps subtlety, not the same as the 
definition of the POSIX "the epoch", which is intentionally vague The 
term "epoch" does not appear in ISO 8601 or any IEC documents I've 
found. Caution with the term "epoch".]


1588 states "7.2.2 Epoch - The PTP epoch is 1 January 1970 00:00:00 TAI, 
which is 31 December 1969 23:59:51.18 UTC.". (This is consistent 
with Steve's statement above - "At 1970-01-01 the difference TAI - 
UTC(BIH) was 8.82 SI seconds."). However, this seems in conflict 
with Annex B, Table B.1 - Relationships between timescales, one entry of 
which says "NTP Seconds = PTP Seconds + 2 208 988 800 - currentUtcOffset".


It seems from long discussions that typical implementations of PTP use 
an integral second relationship between TAI and UTC, as per the 
(non-normative) Annex Table B. If date-time before 1972 UTC is treated 
as integral seconds the same way NTP and POSIX define their origins the 
PTP epoch is 1970-01-01 00:00:00 (TAI) = 1969-12-31T23:59:50 (UTC). This 
is more more consistent with NTP and the typical, or at least some, 
interpretation of POSIX "the epoch".


T

Re: [LEAPSECS] Time math libraries, UTC to TAI

[Brooks Harris]

On 2016-12-30 12:56 PM, Stephen Scott wrote:

NOT "unintentional"

-S


On 2016-12-30 11:37, Brooks Harris wrote:


In SMPTE standards parlance the first sentence is normative, but the 
"Note" is informative. The intention of the note is to inform 
implementers that the intention for SMPTE purposes is to interpret 
the "PTP Epoch" as integral seconds before 1972-01-01T00:00:00Z (UTC). 


Unfortunately, and probably unintentionally, the text leaves some 
ambiguity because the IEEE 1588/PTP states - "... which is 31 
December 1969 23:59:51.18 UTC" while the SMPTE "note" says, and 
the intention is it be, 1969-12-31T23:59:50 (UTC). 
Having been a prime instigator of that note, it was very deliberate 
and not unintentional. It says nothing about UTC prior to 1972. It 
makes clear the relationship between TAI and UTC at 
1972-01-01T00:00:00 (UTC) so that the reader is not misled by the 
ambiguity prior to that date that might be caused by statements in 
IEEE 1588-2008.

-S

Right, I was there, and yes, the point it should be


Having been involved in these discussions I know the intention is the 
latter. The words in a standard matter.


One thing for sure - if we can't agree what a particular timescale's 
origin, or "epoch", means and its exact relationship to 1972-01-01 
00:00:10 (TAI) = 1972-01-01T00:00:00 (UTC) and we don't implement 
them consistently, there won't be interoperability no matter how 
exacting all the other details of the counting schemes may be.


-Brooks


The choice of TAI - 10 would put the origin of the time scale at the
intersection of the grey vertical line and the green horizontal line
seen in the second plot on
http://www.ucolick.org/~sla/leapsecs/amsci.html
And for any system using that time scale that puts the origin at
1.18 SI seconds after the (BIH average of the) radio broadcast
time signals said it was 1970-01-01T00:00:00.

But all of this is pedantic and moot for any currently operational
system because it was not operational then.  Only a few things like
astrometry of solar system bodies and spindown of a handful of pulsars
have data and models with enough precision to discern this.

Everything and everyone else can reasonably assert that they do not
have to care and that every day has always had 86400 seconds of
duration equal to what they are currently ticking.



--
Steve Allen<s...@ucolick.org>   WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165 Lat  
+36.99855

1156 High Street   Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064http://www.ucolick.org/~sla/Hgt +250 m
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Time math libraries, UTC to TAI

[Brooks Harris]

On 2016-12-30 12:39 PM, Steve Allen wrote:

On Fri 2016-12-30T11:37:38 -0500, Brooks Harris hath writ:

There is a hole in the data of these tables; Rec 460 tells us the
origin of TAI is "1 January 1958" but the first TAI-UTC value listed
in the tables is in 1961 - what happened between 1958 and 1961? What
does "1 January 1958" mean; 1958-01-01 00:00:00 (TAI) or 1958-01-01
00:00:00 (UTC)? Wait, did UTC exist in 1958? Why 1958?

This is like learning that the Dow Jones Industrial Average is
calculated from the weighted trade prices of 30 companies and then
asking "Can I use the prices of those 30 companies to calculate what
the DJIA was in 1950?"

All of the companies that have been part of the DJIA, and all of the
weights that have been used, are documented, but the many sites that
publish the DJIA never talk about them.
Right. I forgot to also mention it would be very helpful if the UTC 
specs were collected into a single authoritative reference because a lot 
of implementers get confused and discussions go sideways, even here at 
LEAPSECS.


-Brooks




--
Steve Allen<s...@ucolick.org>  WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street   Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064   http://www.ucolick.org/~sla/   Hgt +250 m
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] The POSIX Time Rationale - in the Working Group's own words

[Brooks Harris]

On 2016-12-30 12:11 PM, Steve Allen wrote:

On Fri 2016-12-30T10:49:19 -0500, Joseph Gwinn hath writ:

It may prove useful to know why the POSIX Working Group (WG) excluded
leap seconds, in their own words.

A bit more insight comes from the 1986 draft POSIX and the
1988 first version of the standard.
http://www.ucolick.org/~sla/coolpix/posixtime/

Even more insight comes from counting that the 1988 standard has far
more text (with more ruminations and consternation) about time zones
than it has about precision time.


It seems obvious to me that POSIX time can't be changed substantially 
since a vast number of systems and applications rely on its behavior. 
Maybe it could be refined a little to make it clearer and to recommend 
more consistent practice, but it must fundamentally retain its 
86400-second-day character. This means it can never accurately reflect 
UTC in all cases, in particular at Leap Second introductions. This 
limitation has been good enough for use by humans "to coordinate 
activity" for a very long time, and will continue to do so, but its 
inadequate for accurate UTC "precision" timekeeping.


It seems to me a "POSIX Time 2" specification could be developed that 
handled UTC correctly and defined mapping to the legacy POSIX time 
(which will necessarily remain ambiguous in those Leap Second cases). 
This could be an addition to POSIX and define behavior of high-level 
APIs that could yield accurate UTC YMDhms representation.


A big part of that challenge there would be to better define local time. 
As Steve points out, local time was a focus of early deliberations and 
remains a critical part of timekeeping considerations because humans 
care about local time, not UTC or TAI. Tz Database is the only source of 
local time information possibly available in the public domain, and has 
essentially become a de facto standard. Its recent inclusion at IANA 
improves its authority and perhaps the chances of eventually finding 
more formal due-process standardization. "POSIX Time 2" could, should, 
better define the meaning of local time and provide the means to 
represent the necessary and sufficient metadata to describe local time.


-Brooks




--
Steve Allen  WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street   Voice: +1 831 459 3046 Lng -122.06015
Santa Cruz, CA 95064   http://www.ucolick.org/~sla/   Hgt +250 m
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Time math libraries, UTC to TAI

[Brooks Harris]

On 2017-01-02 03:07 PM, Michael.Deckers. via LEAPSECS wrote:

  On 2017-01-02 18:55, Brooks Harris wrote about the correspondence

  | Date| MJD| NTP | NTP Timestamp | 
Epoch|
  | 4 Oct 1582  | -100,851   | -3  | 2,873,647,488 | Last day 
Julian  |



Ah, I think the table is correct - that's the infamous reset made by 
the Gregorian calendar  to correct accumulated inaccuracies in the 
Julian and also, I believe, counted days at midnight, not noon, as 
Julian did (does).


   Sure, the Julian date of the day before the day with Gregorian date 
1582-10-25
   is 1582 Oct 04 -- but the epoch given in the table with the MJD 
value and the
   NTP timestamp values is obviously 10 days earlier: they all 
indicate Julian date

   1582 Sep 24 and Gregorian date 1582-10-04, as I have noted earlier.
I'm not understanding where you think there is an error. I think all the 
"Dates" are intended to be Gregorian and proleptic Gregorian, that the 
NTP timestamp example values are on 86400-second-day midnights, and that 
MJD and "proleptic MJD" are treated as 86400-second-days. The values 
seem correct to me by that reckoning.


It is in contrast to the example in
Julian Date Converter
http://aa.usno.navy.mil/data/docs/JulianDate.php

But there, the YMDhms representations are specifically stated to be 
(Julian) and (Gregorian), so its not the same as the NTP table treatment.


   The table indicates the (not usual) confusion about "omitted days" 
where

   it is unclear which numbers should be decreased (or increased) by ten.
   I do not want to be sarcastic but my managers would refuse to buy 
software

   when the spec (already) contains such blunders.
I'm not seeing there is a blunder. However I think it would have been 
more clear if the "Date" column were titled "Gregorian Date".


Note too that the (Last day 20th Century) entry is also on 
86400-second-day boundaries, that there is no Leap Second value applied. 
This is consistent with NTP's behavior, that the 
"seconds-since-NTP-epoch" has been "pulled up" with repsect to 
1972-01-01T00:00:00 (UTC) by the absence of the 23:59:60 count, and so, 
as David Wells has said "In effect, a new timescale is reestablished 
after each new leap second. Thus, all previous leap seconds, not to 
mention the apparent origin of the timescale itself, lurch backward one 
second as each new timescale is established. "


The NTP Timescale and Leap Seconds
https://www.eecis.udel.edu/~mills/leap.html



   And dates in the Julian calendar are taken to begin at midnight, as 
in the
   Gregorian calendar. It is the Julian day numbers used in astronomy 
that
   take integral values at noon epochs -- but they have nothing to do 
with

   the Julian calendar, except perhaps for the origin of the name.


As far as the "Julian" name and the midnight v.s. noon topics, like 
everything in timekeeping there is long history of terms and 
intersection of disciplines. I learn something new with every 
investigation. (thanks, Stephen Scott, for the reference)


Julian Day Numbers by Peter Meyer
http://mooring.ucsd.edu/software/matlab/mfiles/toolbox/misc/timefun/doc/pm_julian.txt
http://www.hermetic.ch/cal_stud/jdn.htm

Note that ITU Rec ITU-R  TF.457-2 and most other explanations of MJD 
have apparently adopted Herschel's astronomical treatment of Julian Days 
(noon-to-noon), but don't explicitly say so.


RECOMMENDATION  ITU-R  TF.457-2, USE  OF  THE  MODIFIED  JULIAN DATE  
BY  THE  STANDARD-FREQUENCY AND  TIME-SIGNAL  SERVICES

http://www.itu.int/rec/R-REC-TF.457-2-199710-I

Now, one could ask, what is the MJD length-of-day after 
1972-01-01T00:00:00 (UTC)? Rec 457-2, nor any other explanations of MJD 
I've seen, says anything about that. I have to take it to mean MJD days 
are always 86400 seconds.


How should the MJD values in IERS Leap_Second_History.dat file be treated?

https://hpiers.obspm.fr/eoppc/bul/bulc/Leap_Second_History.dat

It turns out to be convenient and consistent to treat the MJD values as 
86400-second-days. Thus, to use the (Last day 20th Century) example from 
RFC 5905 Figure 4: Interesting Historic NTP Dates:


   | 31 Dec 1999 | 51,543 | 0   | 3,155,587,200 | Last day 20th|
   | || |   | Century  |

MJD 51543 - 41317 = 10226 MJD days-since-UTC1972 * 86400 = 883526400 
seconds + (32 TAI-UTC - 10) = 883526422 seconds-since-UTC1972.


883526422 seconds-since-UTC1972 + 2272060800 
seconds-NTPEra0-to-UTC1972-offset - 22 Leap Seconds = 3155587200 (NTP 
timestamp)


-Brooks



   Michael Deckers.

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] alternative to smearing

[Brooks Harris]

On 2017-01-05 06:26 AM, Hal Murray wrote:

[do something N years in the future]

Except that's not how things are programmed. Programming it that way would
be very inefficient in a part of the kernel that has to be ultra-efficient.
Since you don't know how many seconds it will from now, you can't schedule a
timeout. The current setup of UTC doesn't let me know how many seconds it
will be in the future. People can talk about it, but computers don't always
store things that way. ...

Are there any performance critical chunks of code that want to wait until N
years from now?  I doubt it.

If I ask for 6 months rather than a few years, then you also have to consider
daylight savings.  Actually, you have to consider it anyway.  Congress might
change the start/stop times again and your wait-until might hit one of them.

I think that means that if you want to schedule something a long time in the
future specified as date and time rather than seconds from now, you have to
wakeup a bit early and recompute how long to wait.  For leap seconds, the bit
early has to be a few months, depending on how long it takes you to update
your leap file.  For daylight savings, I don't think you can predict a value
of a bit early.  Congress isn't dependable.

How far in advance were the last daylight savings changes announced?




Roughly a year and a half or so, I think. I haven't researched when the 
announcement might have officially been made by the Dept of Commerce, 
who, I believe, would have been responsible for that:


Daylight saving time in the United States >> Second extension (2005)
https://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States

"By the Energy Policy Act of 2005, daylight saving time (DST) was 
extended in the United States beginning in 2007.[9]"


"... Wyoming Senator Michael Enzi and Michigan Representative Fred Upton 
advocated the extension from October into November especially to allow 
children to go trick-or-treating in more daylight."


Energy Policy Act of 2005
https://en.wikipedia.org/wiki/Energy_Policy_Act_of_2005

"The Energy Policy Act of (Pub.L. 109–58) is a bill passed by the United 
States Congress on July 29, 2005, and signed into law by President 
George W. Bush on August 8, 2005,..."


I'd put that is a category of "reasonable notice of change", but not all 
jurisdictions are so responsible.


[More generally I'd put the whole notion of Daylight Savings Time in the 
category of "stupid", but there's no fighting city hall]


-Brooks



___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

[Brooks Harris]

On 2017-01-05 05:56 AM, Tony Finch wrote:

Martin Burnicki  wrote:

Please note that NTP servers not necessarily need to be providers for
leap second files. There are some well known sites which provide this
file, and the NTP software package from ntp.org comes with a script
which can be used to update the file automatically.

I was thinking more that an NTP client or server would use its leapseconds
file for validating LI bits from servers and for determining when they
should leap.

My thinking is that routine software patching and security updates happen
often enough that maybe NTP can get leap second more reliably out-of-band
instead of using in-band leap indicators from upstream servers.
Lower-stratum devices could use their own leap second information to
correct for operational or implementation errors upstream.


The potential approach with tzdist or special DNS allowed for a
distributed system, where the special DNS can only provide leap second
warning and the current TAI offset, while tzdist also provides the leap
second history, and a way to update time zone rules, so it could be
generally used to keep also conversion to local time correct.

Oh, I forgot about the DNS publication scheme. That would also help a lot
if it were implemented. And maybe better than relying on sufficiently
frequent software updates.


So, thing is, since 1972, no common and official way to automatically 
obtain the Leap Seconds information has been adopted. Its an obvious 
missing link, missing for 4 decades! I'd find this just incredible 
except I've now come accept this sort of frustration where timekeeping 
is concerned. This has been discussed many times on LEAPSECS.


Ideally there would be one, and only one, TAI-UTC table, in some very 
well specified form, residing somewhere in cyberspace, administered and 
maintained by official rules and regulations by the IERS. There then 
could be many API's via many technologies to access the information.


Today, there are many ways to get it, but they are all in different 
forms, not always so well specified, and all require some human 
intervention or oversight somewhere between the IERS announcements and 
the distribution. None of them are particularly "fast", imposing too 
much overhead on the receiver in some circumstances. And "many ways to 
get it" does not inspire confidence that each implementation will get 
everything the same.


I like the DNS publication scheme because you could imagine that IANA 
could take responsibility for maintaining it, especially if there were 
an official way to keep it automatically updated from a hypothetical 
official IERS source.


One could imagine, and it would be straight forward, to have NTP servers 
provide the TAI-UTC table, announcements, and expiration via the same 
IPC transport mechanisms used by NTP. Again, hopefully, updated from a 
hypothetical official IERS source.


I've had the thought that Block-chain would be a good way to do it. It 
would have all the purported anonymity, security, and persistence 
qualities of Block-chain. In such a scheme, only IERS could make updates 
to it and everybody else could read it.


It makes sense that the Leap Second Table be combined with time zones, 
as it is in Tz Database, because you really need all the local time 
information together with Leap Seconds to achieve comprehensive 
timekeeping. It occurs to me Tz Database could also be maintained as 
Block-chain.


The typical methods used in NTP, GPS, and PTP of distributing only the 
upcoming Leap Second announcement has always seemed fragile and 
incomplete to me. The lack of reliable automatic information from IERS 
means some human intervention must occur in the announcements, and the 
information is incomplete, only communicating the immediate upcoming 
current Leap Second. Many systems will need to go elsewhere to get the 
full table and expiration, and this leads to possible mismatches between 
information sources, as noted in this thread.


Meantime, all this is happening in an environment where the underlying 
specifications are difficult to understand, in some respects possibly 
controversial, and the de facto standards of Tz Database are unofficial 
and don't match Microsoft's world view. I think we really need to go 
back to the top and consolidate the specifications so we agree in detail 
what-all we're trying to accomplish.


-Brooks




Comparing to your example with DNS: If a root server has a software bug
which lets it deliver a wrong IP address, how should your local DNS
resolver detect this?

My analogy was more along the lines of, when a root server IP address
changes, the DNS server notices and logs that it has out of date hints.
It's not a great analogy though, because if the DNS server has the wrong
data about one root server, it can recover using the other 12, but if an
NTP server has wrong data about the next leap second, it's screwed.


I wonder if it would be better to set 

Re: [LEAPSECS] Time math libraries, UTC to TAI

[Brooks Harris]

On 2017-01-07 07:40 AM, Steve Summit wrote:

Brooks Harris wrote:

This is related to Harlan's "General Timestamp API" project, I think.

What's that?


General Timestamp API Project
http://nwtime.org/projects/timestamp-api/

-Brooks

___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] Time math libraries, UTC to TAI

[Brooks Harris]

On 2016-12-31 01:21 AM, Zefram wrote:

Brooks Harris wrote:

There is a hole in the data of these tables; Rec 460 tells us the origin of
TAI is "1 January 1958" but the first TAI-UTC value listed in the tables is
in 1961 - what happened between 1958 and 1961?

You've previously shown some confusion along these lines, and I think
the origin of it is becoming clearer.
I was confused for a long time, that's for sure. I'm not alone. That's 
where I hope, plead, for an authoritative due-process consolidation of 
the UTC specs and local time to emerge from some SDO that would guide 
detailed understanding of the topics. This might help dispel confusion 
and prevent future implementers from suffering the brain damage caused 
by studying and comparing every timekeeping document known to man in 
search of a consistent and common method, which still seems elusive.

You've erred by trying to treat
TAI and UTC as a closely-tied pair, in particular trying to apply the
same threshold dates to them.
I'm not exactly sure what you mean by "threshold dates". This seems like 
a new term, but I get your drift. (Wait, is "drift" the same as "smear"? 
:-) )


I think many on LEAPSECS are pursuing different objectives so it's first 
necessary to state what we are trying to accomplish,.


I came into this from the point of view of television and broadcast 
timekeeping. Here, we deal with the (pesky!) NTSC video rate of 
3/1001 frames per second. That "1001" denominator causes all sorts 
of confusion and implementation difficulty. The media industry relies on 
"SMPTE time code" (SMPTE ST 12) for timekeeping and media labeling 
purposes, and it historically is limited to a "24 hour working period" 
span - it had no accurately defined relationship to UTC or local time. 
But it works deterministically for synchronization and labeling media 
units and has "glued" the entire industry together for many decades.


As SMPTE turned to defining a fixed-epoch timescale for media 
timekeeping and selected IEEE 1588/PTP as the basis for network-based 
media synchronization we are confronted with reconciling the many media 
components and frequencies with accurate time-of-day. The users expect, 
demand, that "time-of-day" mean *local* time-of-day. Humans expect the 
familiar YMDhms representation of local time, or "wall clock".


Meantime, many SMPTE (and other) 1588/PTP implementations will probably 
derive their master PTP clock from GPS. There are millions of PC's 
involved with every OS known to man, so POSIX time and Windows time 
comes into play. And if these don't match NTP reasonably well something 
will obviously be amiss.


So, in my view, this means developing a set of documents that encompass 
all these timescales in such a way as to enable deterministic 
interoperability. We are concerned with keeping accurate date and time 
at and after 1972-01-01 00:00:10 (TAI) = 1972-01-01T00:00:00 (UTC) (call 
this "UTC1972" for short); accurate representation before this instant 
is explicitly out of scope. However, because the NTP, TAI, and POSIX 
origins lie before UTC1972 we must define how these are to be normalized 
to UTC1972.


There are many timescales for many purposes. 1588/PTP cannot represent 
date and time prior to 1970 TAI. GPS cannot represent date and time 
prior to 1980-01-06T00:00:00 (UTC). The mission I'm interested in is 
practical timekeeping after UTC1972 while maintaing reverse 
compatibility to imporat existing timescales.


I applaud the efforts by others to attempt to find consensus of date and 
time prior to 1972. That will be valuable to many disciplines concerned 
with history and its terribly interesting. But it is outside the scope 
of my, and many other's, primary objective of finding a common and 
deterministic formula for describing date and time in the here and now.




One would think that it would be easy to
grasp that different time scales each have their own epoch.  It sounds
like you've gone into this with a preconceived notion that the entirety of
modern horology sprang into existence at a single instant.  You're having
difficulty in abandoning this preconception in the face of evidence.
UTC, with an integral second offset to TAI, *did* spring into existence 
at a single instant; 1972-01-01T00:00:00Z (UTC). I'd call that time 
point the beginning of the modern timekeeping era, the "mother of all 
epochs". Any system that claims to be date and time accurate must 
normalize to this internationally agreed reference point.


The "rubber band" development era, from roughly 1960 (preliminary work 
on atomic clocks was underway) until 1971, when the development had led 
to the convergence of the atomic clock frequency and an *integral* 
second offset to the *new* UTC. As of that moment the historical 
non-integer atomic time-to-solar time values were rendered obsolete. 
What

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

[Brooks Harris]

On 2017-01-08 10:15 AM, Martin Burnicki wrote:

Brooks Harris wrote:

On 2017-01-06 11:52 AM, Martin Burnicki wrote:

- OS kernels with different features (Windows doesn't even know leap
seconds, AFAIK)



It is often repeated on LEAPSECS that "Windows doesn't even know leap
seconds". That's just not true. It knows very well about Leap Seconds in
the same way other systems do but it (typical desktop versions) is lazy
about when it updates - it doesn't attempt to update for Leap Seconds
until the particular system gets round to syncing to some NTP server
(defaulting to time.windows.com, but works perfectly well if set to
time.nist.gov, for example).

Many years ago I wrote a DOS TSR which could read the time from Meinberg
PCI cards (and ISA cards at that time), and adjusted the DOS time if
there was a significant difference.

So of course the DOS time was also adjusted after the plug-in card had
stepped its time due to a leap second.

So according to your argumentation even plain old DOS was aware of leap
seconds, wasn't it?

Yeah, I think so.

Really, none of DOS, Windows, or (pure) POSIX systems "know" about Leap 
Seconds except in so far as the reference counter (Windows FILETIME or 
POSIX time_t, (I can't remember what counter DOS relied on)) has been 
adjusted by the system in response to NTP queries. That adjustment gets 
reflected to YMDhms representation through calls to win::GetSystemTime() 
or POSIX::gmtime(). (Again, long time since I played with DOS, not sure 
the analogous calls)


By the way, DOS was essentially a real-time OS; you could hammer the 
interrupts however you liked. You don't want to do that in a 
multitasking event driven OS.






In Windows, FILETIME (an unsigned 64-bit value) is directly analogous to
POSIX time_t except it has a 1601-01-01 00:00:00 epoch. struct
SYSTEMTIME is analogous to POSIX struct tm ("broken down time" or
"YMDhms" representation). FileTimeToSystemTime() is analogous to POSIX
gmtime();

Like time_t, FILETIME is "bumped" when the system syncs to a NTP server.

Yes because the time adjustment software slews or steps the time.

Which Windows API call can be used to notify Windows that a leap second
is pending, so the Windows system time can account for it at the right time?
I am unaware of any part of Windows that is "aware" of Leap Seconds. 
There's no register somewhere that holds current TAI-UTC, announce, or 
history, I'm pretty sure, not at user-level access to the OS system 
calls, anyway.


(I'm hesitant to state this with great authority because Windows as a 
whole is just huge, and there are APIs on APIs developed and exposed 
over the years. I keep discovering yet another API that may expose 
deeper and deeper access to stuff. There might be something buried 
somewhere that can do this somehow. And Windows is always evolving, so 
something new might exist. Windows Server is something of a different 
animal than regular Windows PC versions, certainly with respect to its 
file system support, so there might be something different there 
regarding timekeeping, I don't know. I've never seen documentation of 
any such thing, though.)


Combinations of SetSystemTime() and SetSystemTimeAdjustment() can adjust 
the system clock. I've never tried to use them to tightly adjust system 
time. It would probably not be an easy project because monitoring 
accurate cause and effect would be tricky. I've played with 
SetSystemTimeAdjustment(), and it definitely changes things a bit, but 
never explored it carefully. But SetSystemTime() certainly works in the 
context of setting values obtained from NTP.


These functions adjust the "System timer" which is responsible for 
user-level FILETIME values and such. This is not the the primary CPU 
clock, of course, which you'd dearly love to frequency lock to an 
outside time source, but I know of no OS level call to do that. Of 
course you could build a driver in ring-zero to give it a go, which 
would be fun, but not a weekend project. :-) (Recommendation: do not try 
anything with interrupts unless you are fond of blue-screens.)


I have never discovered any references to or documentation of exactly 
how Windows synchronizes with NTP. Its a black box. (Any tips on this 
appreciated). But from everything I've been able to observe and 
experiment with it behaves the same as running an NTP client application 
and using SetSystemTime() from the NTP results. That works fine, but 
I've never tried to critically evaluate just how tightly this can be done.


As you probably know, some aspects of the clock and timer behavior 
depend on the CPU model, BIOS, associated chip sets, and the Windows 
power-management scheme in use by a given installation, of which there 
are many from different Windows versions to support available hardware 
technology on a given system. For example, the minimum (average) sleep 
time available from ::Sleep() can vary from, like fr

Re: [LEAPSECS] Leap seconds ain't broken, but most implementations are broken

[Brooks Harris]

On 2017-01-07 02:50 AM, Hal Murray wrote:

leapsecs-requ...@leapsecond.com said:

Right, that's where I say its incredible nothing was done since 1972.  The
Leap Second history is fundamental, and it seems to me an obvious  missing
link. How could it have gone ignored all this time?

Back in the old days, computer clocks weren't accurate enough to care about
leap seconds.

In the early 80s, the NTP equivalent at Xerox was only good to a second and
it was only used at boot time.

By the time computers and networks (and a few geeks) were good enough to
notice, it was too late.
By the 1990s many systems were capable of it, and many were discussing 
how to fix it. Around 2000 we started into the "eliminate Leap Seconds 
debate", which essentially inhibited all development for 15 years. Too 
bad, but here we are now.

-Brooks


Anybody know when NTP supported it's first leap second?




___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs