Re: [LEAPSECS] UT1 offset

[Tom Van Baak]

Hi Mike,

> the system needs an estimate of current UT1

Can you give some references to your observation? I don't recall seeing 
UT1 mentioned in the first couple of decades of GPS documentation. The 
system runs on GPS time, the WGS84 coordinate system, broadcast 
ephemeris including SV clock corrections. Where does UT1 appear in those?


> That estimate is applied internally so the end user does not need to 
know the details


Right, the user is shielded from many details. But I didn't think even 
GPS receivers had knowledge of UT1, nor the satellites themselves. So 
where in "the system" does UT1 apply?


Thanks,
/tvb


On 12/28/2023 1:23 AM, Mike Hapgood - STFC UKRI via LEAPSECS wrote:
Jim outlines a calculation I've done many times. But there's a similar 
calculation for GNSS systems (GPS, Galileo, Beidou, etc). If you want 
to use GNSS to determine positions on Earth's surface to accuracy of a 
few metres, the system needs an estimate of current UT1 accurate at 
least to a few milliseconds. That estimate is applied internally so 
the end user does not need to know the details, just as that user does 
not need to know about the relativistic clock corrections or 
corrections for ionospheric signal delay that also underpin safe use 
of GPS. But the bottom line is that knowledge of UT1 (i.e. the spin 
phase of the Earth) is essential for GNSS - and many other space systems.


Mike


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

Re: [LEAPSECS] speeding up again?

[Tom Van Baak]

Steve,

> We can probably put a lot of the blame onto El Niño

That sounds plausible but I'm suspicious of quick and simple explanations.

You work at/for a university, near the coast, yes? Can you ping some of 
your climatology / oceanography colleagues and get data going back as 
far as they have it? I think it would be useful to see what the 
correlation coefficient actually is.


Attached is an LOD plot I made a while ago. A random web google link 
says "The five strongest El Niño events since 1950 were in the winters 
of 1957-58, 1965-66, 1972-73, 1982-83 and 1997-98". To my eyeball I just 
don't see that in the historical LOD plot.


/tvb


On 5/26/2023 9:09 AM, Steve Allen wrote:

On Mon 2023-05-22T16:44:30+0200 Tony Finch hath writ:

The prospect of a negative leap second is receding. The longer-term
projected length of day from Bulletin A has been increasing towards 24h
in recent months.

We can probably put a lot of the blame onto El Niño

--
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   https://www.ucolick.org/~sla/  Hgt +250 m


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

Re: [LEAPSECS] fb/meta join the leap second haters

[Tom Van Baak]

> But only from 2000 forward, would be interesting to see it

Steven mentioned:

> https://hpiers.obspm.fr/eop-pc/index.php
> which at the moment is showing a Vondrak filtering

"at the moment" is the key; it seems the plot at that URL varies outside 
the control of the visitor. I captured the plot as Steve saw it:


/tvb


On 7/26/2022 11:35 PM, Poul-Henning Kamp wrote:

even better is the view from the Paris bureau at
https://hpiers.obspm.fr/eop-pc/index.php
which at the moment is showing a Vondrak filtering

But only from 2000 forward, would be interesting to see it
for the full data-set.



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

Re: [LEAPSECS] fb/meta join the leap second haters

[Tom Van Baak]

If you go back I'm sure you'll see it mentioned in the LEAPSECS archive. 
When you play with 1962+ data there's a clear ~20 year cycle [1] and, 
more importantly, LOD ends up a bit lower each cycle. So the general 
pattern looks like 20 year arcs back-to-back on top of a gradual trend 
of ELOD going from 2 or 3 ms to 1 or 0 ms the past 60 years.


These arcs are why there's a leap second lull or drought every ~20 years 
and that's why this time around there is even talk about a negative leap 
second. Even if we just barely escape a negative leap second this cycle, 
the trend says we will get one for sure before the end of the next ~20 
year cycle.


This has nothing to do with "tidal braking" which is extremely 
long-term, as in astronomical timescales. Over decades or perhaps 
centuries the not-fully-understood cycles internal to the dynamic earth 
have greater impact.


/tvb

[1] Demetrios has mentioned its the 6939 day Metonic cycle: 
https://en.wikipedia.org/wiki/Metonic_cycle


On 7/26/2022 4:33 PM, Poul-Henning Kamp wrote:

So looking at the IERS LOD plot going all the way back it seems to
me that we have been missing the big signal for about five decades:


https://datacenter.iers.org/singlePlot.php?plotname=EOPC04_14_62-NOW_IAU2000A-LOD=224

How did we not notice that earlier ?



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

Re: [LEAPSECS] 256-week / leap seconds / in the news

[Tom Van Baak]

Steve,

I'm thinking the problem is not with GPS or with modulo arithmetic. I'm 
in contact with Leo and others for the root cause or the scope of the 
problem as reported on twitter. I'll say more later.


Per the GPS ICD, when dt_LS == dt_LSF there is no leap second to speak 
of; not in recent past; not in near future. The 8-bit WN and DN fields 
are not applicable to a non event.


When dt_LS != dt_LSF you know there is a nearby leap second event. You 
then look at WN and DN to determine when. It could have been in the 
recent past, it could be in the near future, or even in progress. By 
"recent past" and "near future" I mean ±127 weeks (about ±2½ years).


Clearly this design means GPS cannot give indefinite past history of a 
previous leap second(s), nor indefinite future notice of a pending leap 
second(s). This is not a problem given how UTC is currently defined and 
managed. BIPM has a good track record of 6 months (~26 weeks) of notice. 
The official UTC spec is 1 month (~4 weeks) of notice so a 127 week GPS 
limit is more than adequate.


/tvb


On 7/25/2021 8:54 AM, Steve Allen wrote:

On Sat 2021-07-24T18:50:50-0700 Tom Van Baak hath writ:

In the news:

"GPS will broadcast a 0 second leap second in 128 days"
https://news.ycombinator.com/item?id=27944776

A tweet from Leo Bodnar electronics about their NTP device
https://twitter.com/LeoBodnar/status/1419239590532206597
which famously includes highlighted text from the section of the GPS
ICD that describes the need to do modulo arithmetic along with the URL
to the new version of the firmware.

--
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   https://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

[LEAPSECS] 256-week / leap seconds / in the news

[Tom Van Baak]

In the news:

"GPS will broadcast a 0 second leap second in 128 days"
https://news.ycombinator.com/item?id=27944776

First, there really isn't a thing called a "0 leap second", but if 
you've read the GPS ICD wrt leap seconds, you can see why it was posted. 
Second, it happened once before, in 2003.


Welcome to another leap second drought. Only this time, it's 2021 
instead of 2003 and u-blox receivers instead of Oncore receivers, so the 
footprint could be several orders of magnitude larger.


Before we worry too much, take your time, follow the links, listen for 
more reports, hopefully we get to see some source code. I've sent some 
emails out to track down details of the symptoms.


/tvb


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

[LEAPSECS] leap seconds, newspapers, earth rotation

[Tom Van Baak]

"Atomic clock scientists suggest shortening minute to 59 seconds"

This is so bad it's funny. [1] A newspaper headline that's inaccurate by 
a factor of, just, 100 million.


Why? If time had 59 minutes per hour instead of 60 the clock rate would 
be off by 0.983  And if we had a leap second (positive or negative, 
doesn't matter), say every 3 years, the clock rate would be off by 
1.06e-8. The ratio of those two is 9.3e7, about 100 million.


From a pedagogical perspective, it's a nice way to demonstrate just how 
tiny a leap second adjustment really is.


By the way, a number of news web sites have been carrying "earth is 
speeding up" and "50 years" stories the past week or so. I've read a 
number of them. Ouch. Does anyone know who started it? Is there a way to 
track it down?


It hope it wasn't LEAPSECS; we have had an influx of members in recent 
months. Fortunately the mailing list has remained very technical, and 
pragmatic about the issue.


Thanks,
/tvb

[1] 
https://nypost.com/2021/01/05/atomic-clock-scientists-suggest-subtracting-a-second-from-minute/



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

Re: [LEAPSECS] "Leap second hiatus"

[Tom Van Baak]

The article also hit /r/programming with a colorful title.

https://www.reddit.com/r/programming/comments/jx6u91/there_has_never_been_a_negative_leap_second_and/.compact

/tvb


On 11/19/2020 3:59 AM, Tom Van Baak wrote:
Today I noticed an unusual number of people suddenly join the LEAPSECS 
mailing list. I tracked down why -- earlier today Tony Finch's blog 
posting about leap seconds got traction on HN, a well-known tech site.


Tony's blog entry is worth reading:

"Leap second hiatus"

https://fanf.dreamwidth.org/133823.html

Some of the user comments are informative:

"Leap second hiatus (fanf.dreamwidth.org)"

https://news.ycombinator.com/item?id=25145870

So, Tony, thanks for the technical content in your blog post, and also 
thanks for choosing a calm and responsible title. Feel free to post 
here with any further info.


Thanks,

/tvb



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

[LEAPSECS] "Leap second hiatus"

[Tom Van Baak]

Today I noticed an unusual number of people suddenly join the LEAPSECS 
mailing list. I tracked down why -- earlier today Tony Finch's blog 
posting about leap seconds got traction on HN, a well-known tech site.


Tony's blog entry is worth reading:

"Leap second hiatus"

https://fanf.dreamwidth.org/133823.html

Some of the user comments are informative:

"Leap second hiatus (fanf.dreamwidth.org)"

https://news.ycombinator.com/item?id=25145870

So, Tony, thanks for the technical content in your blog post, and also 
thanks for choosing a calm and responsible title. Feel free to post here 
with any further info.


Thanks,

/tvb


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

Re: [LEAPSECS] LEAPSECS Digest, Vol 153, Issue 3

[Tom Van Baak]

On 7/15/2020 10:42 AM, Demetrios Matsakis via LEAPSECS wrote:
> There is a well-known decrease in the slow-down due to the global
> warming since the ice ages.   Basically the ice caps melt, the oceans
> rise, and the Earth gets rounder.   But the same people who do that
> math say today’s warming, dramatic as it may be for our biosphere, is
> too little for this particular effect.   People have gotten that
> stuff wrong since George Darwin, though.

Attached are 380k year plots of sea level (lod-msl-fig1.gif) and 
estimated LOD (lod-msl-fig7.gif).


The two papers of interest are cached here:

http://leapsecond.com/pages/lod/2010-Chapanov-Gambis-Long-Variations-Earth-Rotation.pdf
*Long-Periodical Variations of Earth Rotation, Determined from 
Reconstructed Millennial-Scale Glacial Sea Level*

Yavor Chapanov, Daniel Gambis

http://leapsecond.com/pages/lod/2003-Sidall-Glacial_Sea_Lvl_Red_Sea-Na03.pdf
*Sea-level fluctuations during the last glacial cycle**
*M. Siddall, E. J. Rohling, A. Almogi-Labin, Ch. Hemleben, D. Meischner, 
I. Schmelzer, D. A. Smeed


See below for the thread from 2014.

https://pairlist6.pair.net/pipermail/leapsecs/2014-April/005112.html

/tvb

- Original Message -----
From: "Tom Van Baak" 
To: "Leap Second Discussion List" 
Sent: Tuesday, April 15, 2014 8:32 AM
Subject: Re: [LEAPSECS] Earth speeding up?

> I'm not a geophysicist, but I too have noted what Tom reports.  I've 
attached

> a plot that by coincidence I just made last week.
>
> The best hand-waiving arguments I've heard for these recent "decadal 
fluctuations"
> is that the oblateness of the Earth is changing, possibly due to the 
ice caps changing.
> Short-term fluctuations are much better understood, and they 
correlate very strongly

> with the atmospheric angular momentum.
>
> Demetrios,

Thanks for sharing that one. Now, do you dare join the club and predict 
the year when we hit 86400.000?


For a longer-term view, attached are two plots from a 2010 paper 
"Long-Periodical Variations of Earth Rotation, Determined from 
Reconstructed Millennial-Scale Glacial Sea Level" by Chapanov & Gambis 
translating mean sea level to excess LOD.


See also the 2003 Nature paper "Sea-level fluctuations during the last 
glacial cycle" by Siddall & Rohling.


One of these papers is from "New challenges for reference systems and 
numerical standards in astronomy"

http://syrte.obspm.fr/jsr/journees2010/pdf/

Or I can email you copies. I have the raw data here somewhere too.

/tvb

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

Re: [LEAPSECS] Bulletin C number 60

[Tom Van Baak]

> Is it time for a LEAPSECS betting pool on when the first negative 
leap second is deleted?


Yes. Or when UTC will stop having leap seconds, yes.

Here's betting on leap seconds; in a long thread from 2012:

[LEAPSECS] Straw men
https://pairlist6.pair.net/pipermail/leapsecs/2012-January/003762.html

Here's a prediction about 2020; from 2014:

> Any betting person would say the plot shows an upward trend over the
> past 40 years. A simple linear fit suggests the earth will be back to an
> honest 86400 second day within a few years, around MJD ~59000 (year 
~2020).


[LEAPSECS] earth speeding up
https://pairlist6.pair.net/pipermail/leapsecs/2014-April/005102.html

Attached are the plots from the above posting.

/tvb

On 7/12/2020 8:07 AM, Poul-Henning Kamp wrote:


Tony Finch writes:


The LOD is hovering around 0 and the UT1-UTC chart is looking remarkably flat.

https://datacenter.iers.org/singlePlot.php?plotname=FinalsAllIAU2000A-UT1-UTC-BULA=9

https://datacenter.iers.org/singlePlot.php?plotname=FinalsAllIAU2000A-LOD-BULA=9

Is it time for a LEAPSECS betting pool on when the first negative leap second 
is deleted ?



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

[LEAPSECS] Another vote on UTC, facebook

[Tom Van Baak]

Recent news; another middle-finger to UTC as currently, legally defined.

"Building a more accurate time service at Facebook scale"
https://engineering.fb.com/production-engineering/ntp-service/

"Facebook Switches to New Timekeeping Service"
https://spectrum.ieee.org/tech-talk/telecom/internet/facebook-new-time-keeping-service

Unfortunately, I don't see a white paper, code, or technical details on 
positive/negative smear duration or slew rate, so we don't know if at 
the ms level it's the same as Google or Amazon or others on this bandwagon.


If you're one of the facebook devs working on the project and you see 
this posting, please help the leap second community with technical details.


Thanks,
/tvb


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

Re: [LEAPSECS] Executive Order on Strengthening National Resilience through Responsible Use of Positioning, Navigation, and Timing Services

[Tom Van Baak]

>> 2 (or more) Loran-C stations gave you more accurate time. But if you
>> know where you are, and since the stations don't move, you can
>> manually adjust for signal propagation delay to some extent. This is
>> not unlike how one obtains time from WWV or WWVB.
>
> One of the big issues with LORAN C, I thought, was that those
> variations were measured in microseconds...

Right, the variations are huge compared to GPS. Microseconds (Loran), 
even milliseconds (WWV*). So that's why when people talk about a "source 
of UTC" the accuracy should be specified. Otherwise a even wristwatch or 
sundial could be considered a source of UTC.


> But I guess those average out over time so if you have a stable local
> oscillator you can recover time fairly well.

Before Loran-C was canceled and before the WWVB format was "enhanced" 
there were a number of disciplined time & frequency products that did 
just that. Stuff from Austron, Spectracom, and SRS. Some of us time nuts 
have this gear.


> Fun fact, LORAN has no leap seconds (since it is just a bunch of
> different rates). So to calculate time of coincidences with UTC you
> had to basically use TAI - 10s since the LORAN signal is paced with
> SI seconds. When I was working on the replacement timing system for
> the LORAN chains, this was a big deal since to start LORAN you needed
> to know both the UTC time and a recent / near future table of leap
> seconds... This leads to a lot of edge cases, especially when you
> needed to cope with the cold spare GPS reciever case. :(. It's also
> where all the love I feel for leap seconds left my body...

Yes, exactly. BTW, Loran TOC (for the 9940 chain) is available here:

http://leapsecond.com/java/gpsclock.htm

USNO used to publish Loran-C TOC tables for all the chains on their web 
site. Last year most of their user-facing pages went away.


/tvb


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

Re: [LEAPSECS] Executive Order on Strengthening National Resilience through Responsible Use of Positioning, Navigation, and Timing Services

[Tom Van Baak]

> Within 180 days of the date of this order, the Secretary of Commerce 
shall

> make available a GNSS-independent source of Coordinated Universal Time,
> to support the needs of critical infrastructure owners and operators,
> for the public and private sectors to access.

And I hope by "source of Coordinated Universal Time" they mean not just 
a time value, but also the metadata necessary to implement leap seconds. 
That's as little as 2 bits to indicate pending leap status in the 
current month (as WWV* does it) or UTC offset information (as GPS does 
it), etc.


Also not clear if this new source of UTC must be secure and jam 
resistant. If so, that eliminates the WWV* stations as well as NIST / 
USNO telephone time as the solution.


/tvb

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

Re: [LEAPSECS] Executive Order on Strengthening National Resilience through Responsible Use of Positioning, Navigation, and Timing Services

[Tom Van Baak]

> I thought of Loran...  but you need 2 stations for time, I thought...

2 (or more) Loran-C stations gave you more accurate time. But if you 
know where you are, and since the stations don't move, you can manually 
adjust for signal propagation delay to some extent. This is not unlike 
how one obtains time from WWV or WWVB.


/tvb

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

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

[Tom Van Baak]

  
  
Hi Hal,
It's 2020. How on earth can NTP still not implement UTC
  correctly, in all cases? Or is it a fundamental NTP design flaw?

The Z3801A issue doesn't sound like an NTP problem. This is a
  known legacy Z3801A f/w or Motorola Oncore problem, yes? Maybe
  also affected by one or even two GPS WNRO problems buy now?

/tvb

On 2/6/2020 1:41 AM, Hal Murray wrote:


  
tvb said:

  
There's no ambiguity. Those are just bugs. No software should depend on  more
than 1 month notice of a leap second and no software should be  fooled if the
notice is months or even years in advance. 

  
  
There are plenty of quirks in ntp code along that line.  The APIs don't have 
an explicit when.  The NTP-Kernal API for leap-pending is leap-tonight.  You 
have most of the next day to turn it off.  The leap-pending on the wire is 
leap-at-the-end-of-this-month.

I fixed a bug in the Z3801 driver by ignoring a leap pending unless it was 
June or December.  It's a hack, but it gets the job done and the code wasn't 
setup to ask it when the leap would happen.


tvb said:

  
If you're writing a FAQ or best practices guide stay in touch. I have a
semi-technical leap second report in the works. UTC is actually very  simple;
but it's been complicated by untold levels of bad assumptions,  bad
execution, and bad prose. 

  
  
Are you going to say anything about POSIX?





  

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

Re: [LEAPSECS] Leap seconds have a larger context than POSIX

[Tom Van Baak]

Warner,

> Yes. I wish it were clearer that TAI time is a regular radio 
expression of time.
> Here regular radix means that it every day has 24 hours and every 
hour 60 minutes

> and every minute has 60 seconds.

I'm not sure it's fundamental to TAI that one must always, or only, use 
24x60x60 radix notation. That's a useful convention in many cases, but 
at the h/w counter or s/w binary integer level radix notation is not 
required.


The key features of that timescale are its rate, its epoch, its 
continuity, and its lack of physical, astronomical, or political 
interference. A side effect is that this is a timescale that can be 
converted to/from broken-down date/time format in perpetuity using 
simple math and without using external tables.



> At the moment there are only two opportunities to consider, though the
> standard allows up to end of every month.

Code should allow for a leap second event at the end of any month. The 
June / December thing is one of several guidelines for BIPM; it's not a 
rule that anyone writing UTC code should assume or depend on. Nor should 
code ever assume leap seconds are positive.


> This ambiguity has lead to bugs when leaps were announced more than 3 
months
> in advance. I'd feel better if there were a commitment to these 
parameters for some

> number of years. But it's all just convention today.

There's no ambiguity. Those are just bugs. No software should depend on 
more than 1 month notice of a leap second and no software should be 
fooled if the notice is months or even years in advance.



> Have I forgotten any of the other details of leap seconds that are more
> tribal knowledge than rigorously specified?

If you're writing a FAQ or best practices guide stay in touch. I have a 
semi-technical leap second report in the works. UTC is actually very 
simple; but it's been complicated by untold levels of bad assumptions, 
bad execution, and bad prose.


/tvb

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

Re: [LEAPSECS] leap seconds in POSIX

[Tom Van Baak]

Hal,

I see some good comments; did you get the answer you wanted? My take:

> Does anybody know of a good writeup of how to fix POSIX to know about 
leap seconds

> and/or why POSIX hasn't done anything about it yet?

No write-up. No fix. It's not possible without breaking h/w, f/w, s/w, 
and time_t.




Note this is not a POSIX issue per se. All POSIX did was rubber stamp 
and formalize what various versions of UNIX did at the time. The method 
of linear timekeeping where you pick an origin and count regular time 
intervals was widely used in other systems of the era too: from 
wristwatches to wall clocks, from astronomical time to telephone time, 
from mainframes to minicomputers. They all fail to handle leap seconds.


If necessary, for a given application, you may be able to hack your way 
around leap seconds. But it's not POSIX then.


One practical work-around is to recognize that the words UTC or POSIX or 
time_t do not contain an accuracy specification. Thus you can weasel 
your way out and claim "one second or worse" accuracy and simply gloss 
over the existence of leap seconds.


However, this work-around fails if you are required to provide 
sub-second accuracy. Then you're stuck providing true UTC, leap seconds 
and all.


/tvb


On 1/27/2020 12:59 AM, Hal Murray wrote:

Does anybody know of a good writeup of how to fix POSIX to know about leap
seconds and/or why POSIX hasn't done anything about it yet?

I assume the basic idea would be something like switch the kernel to use TAI
rather than UTC and implement conversion in some library routines.


There is a discussion on the IETF ntp list with typical S/N for this topic.



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

Re: [LEAPSECS] aircraft GPS receivers hit by leap second bug

[Tom Van Baak]

> However, the current GPS/UTC offset numbers before and after the nearest
> leap seconds are still 18/18, so there is no current leap second
> announcement, and WNlsf may be ambiguous.

Perhaps call it "immaterial" rather than "ambiguous"? The fact that it's 
18/18 means no positive or negative leap second is pending. Period.


In other words, the value of WNlsf doesn't matter in this case. It's an 
8-bit value so obviously it must always be something between 0x00 and 
0xFF, or -128 to +127. Maybe it's a recent old value, maybe it's zero, 
maybe a future new value, or maybe random. It doesn't matter. What 
matters first are the tLS and tFLS values, which are currently 18/18 -- 
which means no leap second. Period.


A similar issue arose in some GPS receivers during the 7 year "leap 
second drought" of 1998 to 2005. [1]


Here's the math:

 * GPS start date: 1980-01-06 (MJD 44244)
 * Most recent leap second: end of the day 2016-12-31 (MJD 57753)
 * Most recent leap second: prior to the day 2017-01-01 (MJD 57754)
 * Date of first Collins / GPS / ADS-B anomaly: 2019-06-09 (MJD 58643)
 * Date that Collins says their systems will start working again:
   2019-06-16 (MJD 58650)

Note that (58650 - 57754) / 7 = 128.000

So it's a big Rockwell-Collins oops. Both the GPS receiver firmware 
engineer who wrote the embedded code and the tester using a fancy GPS 
simulator dropped the ball.


/tvb

[1] http://www.leapsecond.com/notes/leapsec256.htm


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

[LEAPSECS] Fw: Second UT1 time server

[Tom Van Baak]

FYI

- Original Message - 
From: "Judah Levine" 
To: "Tom Van Baak" 
Sent: Tuesday, February 19, 2019 9:18 AM
Subject: Second UT1 time server

> I have installed a second UT1 time server. It will be in Fort Collins,
> with address 132.163.97.7
> This will be in addition to the current UT1 time server in JILA.
> 
> Please forward to any interested colleagues.
> 
> Judah
>

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

Re: [LEAPSECS] is leap smear legal in Germany?

[Tom Van Baak]

Steve, et al.

Some good history resources:

"Special Topic 50 years of time dissemination with DCF77"
https://www.ptb.de/cms/fileadmin/internet/fachabteilungen/abteilung_4/4.4_zeit_und_frequenz/pdf/2011_PTBMitt_50a_DCF77_engl.pdf

"Time - the SI Base Unit Second"
https://www.ptb.de/cms/fileadmin/internet/fachabteilungen/abteilung_4/4.4_zeit_und_frequenz/pdf/2012_Bauch_PTBM_125a_en.pdf

The above is of special interest to me (being both a pendulum and atomic clock 
experimenter) is the mention of A. Scheibe and U. Adelsberger who used multiple 
quartz clocks to demonstrate that it was the earth, not pendulum clocks, not 
quartz clocks that was unstable.

"A. Scheibe und U. Adelsberger; Physiker und Uhrenbauer aus Deutschland"
http://chronos-ev.de/vortrag/quarz5.pdf

"Some aspects of precision time measurements, controlled by means of
 piezo-electric-vibrators, as deployed in Germany prior to 1950"
http://www.cdvandt.org/PTR%20quartz-clock.pdf

The above mentions "The first statistical proof of the deviations of the daily 
earth rotation".

"Special Issue; The System of Units"
https://www.ptb.de/cms/fileadmin/internet/publikationen/ptb_mitteilungen/mitt2012/Heft1/PTB-Mitteilungen_2012_Heft_1_en.pdf

"50 Years of the Atomic Definition of the Second"
https://oar.ptb.de/files/download/59ef10144c918497222d9bb7

"Fifty years of atomic time-keeping: 1955 to 2005"
DOI: 10.1088/0026-1394/42/3/E01

"The 50th Anniversary of the Atomic Second"
DOI: 10.1109/TUFFC.2018.2823591

More (possible dead) links here: 
https://www.febo.com/pipermail/time-nuts/2005-July/019010.html

/tvb

- Original Message - 
From: "Steve Allen" 
To: "Leap Second Discussion List" 
Sent: Saturday, February 02, 2019 8:27 AM
Subject: [LEAPSECS] is leap smear legal in Germany?


> The story about the German time broadcasts of DCF77 is in Bulletin
> Horaire.  The story about the German decision that the old rubber
> second UTC form of coordination was not legal after CGPM adopted
> the cesium second is in the proceedings of the CCDS, and it is
> also indicated in several popular articles written by H.M. Smith.
>
...

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

[LEAPSECS] Of stepping motors and leap seconds

[Tom Van Baak]

A leap second related story problem.

After visit to USNO years ago I wanted to make a leap second desk clock as a 
thank you gift. The idea was to use a standard 32 kHz quartz clock stepper 
movement [1] [2] but drive it with a microcontroller such that during a leap 
second it slows down for a bit. I've hacked such clocks in the past; it's quite 
easy. [3]

Now Google smears the leap second over an entire day; which is quite a long 
smear. I understand the NTP-related motivation for this. My clock was a very 
short smear. Note that if you have a digital display no smear is necessary 
since you can drop a :59 or add a :60 with ease. LED or LCD digits display 
instantly. But if you have a "real" clock, one with analog hands, you can 
neither display a :60, nor drop a :59, nor can you do anything instantly. The 
physics of electro-magnetism, motors, and inertia prevents that. Hence the name 
"smooth" back then, although thanks to Google, I now much prefer smear.



I never finished the project. But here's the math.

a) For a positive leap second one can tick normally through :57 and :58 and :59 
and then reduce the clock to half speed for 2 SI seconds. This will result in 
the clock spending two seconds to get from :59 to :00 at which point it will 
again be in sync with UTC at the top of the hour. It seemed the simplest way to 
get an analog clock to mimic a leap second.

b) For a negative leap second one can tick normally through :57 and :58 and 
then increase the clock to double speed for 1 SI second. This will result in 
the clock spending one second to get from :58 through :59 to :00 and it will 
again be in sync with UTC at the top of the hour. Also very simple.

What I liked about these two methods is the symmetry. Both positive and 
negative leaps are a smear. In one case you 1/2x the speed for 2x the time; in 
the other you 2x the speed for 1x the time. A negative leap second is more fun 
to watch since it's 4x the rate of a positive leap second. Either way, the 
result is the required one second phase change in the analog dial display.

These ideas were inspired by a vintage Junghans DCF77 / WWVB analog clock. 
During synchronization it enters a rapid tick mode (like a negative leap 
second) and when low on battery it enters a half tick mode (like a positive 
leap second).



Now back to Google and its ~24 hour smear. One feature of their approach is 
they center the smear around midnight. What happens if this is done with a 
short smear analog clock?

c) For a positive leap second you could start the 1/2x clock slowdown at :59.5. 
It will last for 2 SI seconds and end at :00.5. This is the same as case (a) 
except it starts half second later in order to be centered across midnight.

But given that these analog clock hands can't rest at half-second marks, this 
solution feels awkward. So another approach might be a 2/3x clock slowdown 
starting at :59 that lasts for 3 SI seconds and ends at :01. This avoids the 
half-second problem and still keeps the leap centered. Other numerical 
solutions follow the same N/M rate pattern.

d) For a negative leap second one could increase the clock to 2x speed at :59 
and end at :01. This is the same as case (b) except it begins 1 second later in 
order to be centered across midnight rather than end at midnight.

There is still symmetry in cases (c) and (d) but the rate fractions get a bit 
more complicated.



A further level of complication with Google's next smear is (I think) they want 
to start 12h before midnight (pre-leap) and end 12h after midnight (post-leap). 
This suggests the actual number of SI seconds on either side of midnight will 
differ by 1 which may imply the true center of the smear isn't actually at 
midnight.

Anyway, if any of you are interested in this sort of thing, let me know. The 
larger topic is not a quartz desk clock per-se, but investigation into 
different ways to implement short smears, as one might do in a quartz clock, or 
a cesium standard, or an operating system that wants to get the leap second 
over with as quickly as possible instead of as slowly as possible.

I'm wondering how the LEAPSECS crowd feels about long or short smears. One way 
to measure this is the area under the curve. For a 24 hour smear the |error| 
ramp goes from 0 to 0.5 to 0 over 24 hours; so that's an integrated error area 
of 6 hour-seconds. For a short smear it's more like 1 second-second.

/tvb

[1] https://en.wikipedia.org/wiki/Lavet-type_stepping_motor

[2] https://en.wikipedia.org/wiki/Quartz_clock

[3] http://leapsecond.com/pages/32kHz/

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

Re: [LEAPSECS] the epoch of TAI, with no more doubt

[Tom Van Baak]

> The epoch at which TAI was set is definitely 1961-01-01T20:00:00 UT2
> 
> https://www.ucolick.org/~sla/leapsecs/taiepoch.html

I'm curious how your findings compare with this random link I ran across [1]:

https://koka-lang.github.io/koka/doc/std_time_utc.html

See especially section "1.3. UTC before 1961"

and also the link:
https://books.google.com/books?id=uJ4JhGJANb4C=PA87=wwv=PA87#v=onepage=wwv=false

Give it some thought. I don't have a quick answer and would appreciate your 
input. If you've ever worked with raw UTC(k) data, present or historical, you 
know there's no one right time. So in the late 1950's, making claims about 
Paris vs. Washington / Gaithersburg / Boulder might not be as clear as you hope.

In my home museum the earliest cesium standard is 9,192,631,840 Hz not 
9,192,631,770 [2]. I've learned that re-interpreting international time & 
frequency history is not always simple.

/tvb

[1] I don't necessarily endorse this page; having not spent enough time with 
it. As a serious hands-on atomic clock experimenter I am often repelled by 
arm-chair software engineers who try to recreate time & frequency standards 
history with their table lookups and pretend proleptic extrapolations.

[2] http://leapsecond.com/museum/nc2001/freq2.jpg
via http://leapsecond.com/museum/nc2001/

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

Re: [LEAPSECS] leapseconds, converting between GPS time (week, second) and UTC

[Tom Van Baak]

> If you set your POSIX system clock at TAI minus 10 seconds then
> it keeps track of the number of seconds which have been counted
> in the internationally approved radio broadcast time scales.

So, wait. In order to use Python for any proper UTC processing you have to 
configure your PC to run on TAI? That sounds, sort of inconvenient if you're 
trying to do anything with precise time. It's the same as Excel.

Still, I bet more astronomers use Python than Excel to point telescopes. How do 
you handle the lack of leap second support in Python?

/tvb

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

Re: [LEAPSECS] leapseconds, converting between GPS time (week, second) and UTC

[Tom Van Baak]

> Yo Tom!
>
> On Tue, 15 Jan 2019 10:50:10 -0800
> "Tom Van Baak"  wrote:
>
> > Nope. All minutes have 60 seconds in Excel. And in Windows. And in
> > Unix/POSIX.
>
> Not quite.  Check out "man gmtime" for one way that POSIX represents time.
>
> Specifically:
>
>struct tm {
> [...]
>int tm_sec;/* Seconds (0-60) */
>
> gmtime() is perfectly capable of reporting 61 seconds in a minute.

Hi Gary,

Nice to hear from you.

But the underlying time_t cannot represent leap seconds, can it? So how does 
that gmtime hackery work?
Also, presumably Python is based on POSIX? Does it use time_t or gmtime? Why 
did Jim's quick Python experiment fail?

/tvb

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

Re: [LEAPSECS] leapseconds, converting between GPS time (week, second) and UTC

[Tom Van Baak]

Jim -- I'm replying via the LEAPSECS list because we love leap second questions 
here.

List -- Jim is a long-time member of time-nuts, works at JPL, and does 
wonderful stuff.

>From Jim Lux:
> I'm working with a variety of things which work in UTC or GPS 
> week/millisecond, so we're doing a lot of conversion back and forth.
> (the spacecraft puts out time in week:millisecond, all the ground 
> systems processing is in UTC)
>
> The question comes up when converting back and forth, and whether 
> various libraries handle leap seconds correctly.
> For now, I can use a hack of not computing back to 6 Jan 1980, but use 
> an epoch like 15 Dec 2018 (week 2031: 518,400.000 seconds) and hope 
> there's no leap second in the offing.

Yes, that's one way. But that doesn't sound safe or correct to me.

> For instance, in Python, if I do a datetime(2016,12,31,0,0,0) + 
> timedelta(hours=30) does it come out as 1/1/2017 6:00:00 or 5:59:59  (it 
> comes out 0600)
>
> Similarly, does Excel's time formatting allow for some minutes having an 
> extra second, or does it just assume all minutes are 60 seconds.

Nope. All minutes have 60 seconds in Excel. And in Windows. And in Unix/POSIX. 
Really any computer system that uses a fixed "epoch" and a ticking "counter" is 
ruined by leap seconds. The systems differ in their epoch's, they all differ in 
their counters, they can all be set to UTC, except they all fail when there's a 
positive or negative leap second.

> I'll probably test it for the cases I'm interested in (Ruby, Python, 
> Excel, Matlab, Octave), but if someone else has already done it, then 
> I've got something to cross check against.

This is a good question for LEAPSECS. I suspect those packages are well-known 
here.

> (python does NOT know about leap seconds)
>
> import datetime
>
> d = datetime.datetime(2016,12,31)
>
> dt = datetime.timedelta(hours=30)
>
> d
> Out[4]: datetime.datetime(2016, 12, 31, 0, 0)
>
> dt
> Out[5]: datetime.timedelta(1, 21600)
>
> d+dt
> Out[6]: datetime.datetime(2017, 1, 1, 6, 0)

Right, this is typical for almost any software developed anywhere. Leap seconds 
are such a weird exception, almost no commercial software, web frontend or 
backend, or mobile phones, or mobile apps deal with them correctly.

I'm hoping a number of LEAPSECS members can chime in. There are astronomers 
here who must be used to solving issues like this, in python or other tools, so 
their input would be valuable.

/tvb

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

[LEAPSECS] leap seconds rarely happen at midnight

[Tom Van Baak]

Nice take on time zones (applies to leap seconds also):

https://xkcd.com/2092/

/tvb

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

Re: [LEAPSECS] Windows 10 HOME leap second changes

[Tom Van Baak]

Good questions, and there are many more.

Maybe let's see if there's a way to contact the blog posters by email or phone. 
For something as important as true-UTC timekeeping on Windows, especially at 
the enterprise level, I'd expect to read formal technical specifications 
instead of a pair of folksy blog entries. It's hard to tell if this was 
intended as a comprehensive adoption of leap seconds for Microsoft products, or 
a one-time compliance check-list hack for certain high dollar customers. There 
are lots of red flags.

BTW, the TAI comment that you posted on the blog was fine; the reply was 
somewhere between defensive and wrong.

/tvb

- Original Message - 
From: "GERRY ASHTON" 
To: "Leap Second Discussion List" 
Sent: Thursday, October 25, 2018 7:54 AM
Subject: [LEAPSECS] Windows 10 HOME leap second changes


> I was reading the two Microsoft blogs mentioned on the list in the last few 
> days. The Windows time service seems to be w32tm. From the behavior of my 
> laptop, I infer that this service is not normally running. I guess it is 
> started when it's time to sync the clock to an NTP time server, and stopped 
> when the syncing is finished. Does anyone know if that's true?
> 
> Does anyone know if the access to leap seconds by applications will be in 
> home systems, or other systems that are not joined to a domain? (Not that I 
> think such systems will have a serious need for such accuracy, but it might 
> be interesting for tinkerers.)
> 
> Gerry 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] more Windows 10 leap details

[Tom Van Baak]

Part 2 of the blog is just out:

https://blogs.technet.microsoft.com/networking/2018/10/24/leap-seconds-for-the-appdev-what-you-should-know/

Note the new, per-process compatibility mode default is a 2 second or ½ second 
leap smear. Fun times ahead.

/tvb

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

Re: [LEAPSECS] no more listening to leap seconds?

[Tom Van Baak]

Hi Steve,

>From what I understand the same "threat" occurred in 2017 with the FY18 
>budget. In the end, the budget ended up greater even than what was asked. So 
>no cuts were made. Who knows what will happen this time. Still, it's always a 
>concern; for the staff, for the time service, for the users. The greater issue 
>is to maintain a comprehensive national or global time dissemination system, 
>with deep and multiple levels of accuracy, redundancy, security, and 
>resiliency.

My guess is we will still be able to "hear" leap seconds -- just tune into 
Google and listen to the sound of innocent SI seconds being compressed or 
stretched to levels not seen since medieval timekeeping. The unpredictable 
clock arrest, which starts sometime around midnight, the prolonged shrieks of 
pain from the rack. The horror; the smell of leap seconds in the morning; 
Charlie don't leap.

/tvb

- Original Message - 
From: "Steve Allen" 
To: "Leap Second Discussion List" 
Sent: Friday, August 10, 2018 1:25 PM
Subject: [LEAPSECS] no more listening to leap seconds?


> This crossing over from time-nuts list, but it may mean that
> listening to leap seconds will become a thing of the past.
> If I understand this summary of the NIST budget request then
> radio stations WWV, and WWVH are set to be shut down.
> 
> https://www.nist.gov/director/fy-2019-presidential-budget-request-summary/fundamental-measurement-quantum-science-and
> 
> --
> 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

[LEAPSECS] New GPS Interface Specification IS-GPS-200J is out

[Tom Van Baak]

See below. Cross post from time-nuts...

BTW, have a look at how many bits the EOP parameters have, including DUT1, 
DUT1/day. That should keep astronomers happy for a while.

/tvb

- Original Message - 
From: "Tom Van Baak" 
To: "Discussion of precise time and frequency measurement" 

Sent: Monday, July 30, 2018 1:56 PM
Subject: Re: New GPS Interface Specification IS-GPS-200J is out

Thanks Leo.

For you low level time nerds, yes, even DoD can't get GPS time / UTC / UT1 / 
leap seconds right the first time. Synchronizing 3 time scales across a leap 
second discontinuity is really, really hard. More info about ICD rev-J here:

https://www.gps.gov/technical/icwg/meetings/2018/PIRN-IS-200J-001.pdf
"RFC Title: 2018 Proposed Changes to the Public Documents"

or search for RFC 374 here (page 67/117):

https://www.gps.gov/technical/icwg/meetings/2017/presentation.pdf
"Global Positioning Systems (GPS) Public Interface Control Working Group and 
Public Forum"

/tvb

- Original Message - 
From: "Leo Bodnar" 
To: 
Sent: Monday, July 30, 2018 12:58 PM
Subject: [time-nuts] New GPS Interface Specification IS-GPS-200J is out

> Hi,
> 
> For those who missed it - IS-GPS-200 has been updated a few months ago.
> 
> https://www.gps.gov/technical/icwg/IS-GPS-200J.pdf
> 
> Leo Bodnar


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

[LEAPSECS] comments on UTC

[Tom Van Baak]

Below are recent threads about UTC on HN & reddit. There's a few comments about 
leap seconds as well. Read it not so much to learn something new about UTC or 
leap seconds, but to get a snapshot of real world timing problems that 
programmers face.

"UTC Is Enough for Everyone, Right?"
https://news.ycombinator.com/item?id=17181046

"UTC Is Enough for Everyone, Right?"
https://www.reddit.com/r/programming/comments/8n1rrd/utc_is_enough_for_everyone_right/.compact?limit=500

/tvb

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

Re: [LEAPSECS] current / future state of UT1 access?

[Tom Van Baak]

Reply from Judah below:
/tvb

- Original Message - 
From: Levine, Judah Dr. (Fed) 
Sent: Tuesday, March 20, 2018 6:49 AM
Subject: Re: [Non-DoD Source] Re: [LEAPSECS] current / future state of UT1 
access?


Dear colleagues,
   The current UT1 time server has 550 users and is receiving about 10 requests 
per second. These are both extremely small numbers compared to my other 
servers. I cannot explain Rob Seaman’s experience. I routinely monitor all of 
the servers and do not see this problem. I have not received any other 
complaints about the service. 
  In spite of all of this, there is no difficulty in adding a second UT1 time 
server at another location. From my perspective, the easiest solution would be 
to add the second UT1 server at WWV. The IP address of the new server would be 
132.163.97.x. There are already 4 servers at this site with addresses 
132.163.97.1-4, and I encourage the community to verify that these servers are 
available from a network perspective. 


Judah Levine





On: 19 March 2018 11:33, "Matsakis, Demetrios N CIV NAVOBSY, N3TS" 
 wrote:

FYI.

If you wish me to relay a message to this group, I'd be willing to.

From: LEAPSECS [leapsecs-boun...@leapsecond.com] on behalf of Rob Seaman 
[sea...@lpl.arizona.edu]
Sent: Monday, March 19, 2018 1:30 PM
To: leapsecs@leapsecond.com
Subject: [Non-DoD Source] Re: [LEAPSECS] current / future state of UT1 access?


I appreciate the feedback from everybody on the UT1 NTP issue. I have yet to 
successfully connect from campus and possibly Martin's comment applies since 
there are a lot of telescopes and astronomers here working for several 
observatories. Somebody else on this end may be bogarting the NIST UT1 (though 
we get through fine to their UTC servers).

The issue has come up now since a colleague asked about best practices for 
access to UT1. In the mean time he's implemented yet another internet retrieval 
of Bulletin A. Perhaps it needs to be stressed again, astronomers require 
access to both Universal Time and Atomic Time.

The NIST UT1 server is not currently useful for our purposes. Perhaps a UT1 
pool will make sense at some point? If the NIST servers are all loaded "sky 
high", is there any plan to mitigate this through data center / networking best 
practices? We have seen their other servers' reach faltering at this end, too.

Thanks!

Rob

--


On 3/19/18 7:43 AM, Martin Burnicki wrote:

Please note you need to take care if you have several nodes behind a NAT
router that poll the same server. From the server's point of view it
looks like all the requests from the nodes behind the router seem to
come from the same (public) IP address, so a particular node on the NAT
subnet may receive even less replies.

On 3/19/18 9:48 AM, Poul-Henning Kamp wrote:

You can simply test this if you run "ntpdate -d -p1 "
repeatedly. When I try this for a NIST server here from Germany I only
receive a reply occasionally, and in most cases I don't.


Last I heard about it, the packet load on the NIST servers were
sky high so I am not the least surprised...

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

[LEAPSECS] That's why we have leap seconds

[Tom Van Baak]

Finally, leap seconds get mentioned in xkcd:

https://xkcd.com/1930/

Older timekeeping-related postings:

https://what-if.xkcd.com/26/
https://xkcd.com/1514/
https://xkcd.com/1061/

/tvb

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

Re: [LEAPSECS] Ramifications of DST -Brooks

[Tom Van Baak]

Brooks,

Clever.

The attachment was a bit blurred (color depth, copy/paste?). Here's a full-res 
version:

https://i.imgur.com/nxFWLpn.jpg

/tvb

- Original Message - 
From: "Brooks Harris" 
To: "Leap Second Discussion List" 
Sent: Sunday, November 05, 2017 5:04 PM
Subject: [LEAPSECS] Ramifications of DST -Brooks


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

[LEAPSECS] new delta-T data point

[Tom Van Baak]

In the news...

https://academic.oup.com/astrogeo/article/58/5/5.39/4159289/Solar-eclipse-of-1207-BC-helps-to-date
( https://academic.oup.com/astrogeo/article-pdf/58/5/5.39/20098470/atx178.pdf )

Some other related links:

http://rspa.royalsocietypublishing.org/content/472/2196/20160404
( 
http://rspa.royalsocietypublishing.org/content/royprsa/472/2196/20160404.full.pdf
 )

http://adsabs.harvard.edu/full/2002HiA12..338M

http://adsabs.harvard.edu/full/2004JHA35..327M

http://adsabs.harvard.edu/full/2005A%26G46e..11S

https://eclipse.gsfc.nasa.gov/SEhelp/deltaT2.html

/tvb

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

Re: [LEAPSECS] leap second roundup 2017

[Tom Van Baak]

> By that logic, one should avoid any interval that includes June 30 or
> December 31, since such an interval might include a leap second.

John,

Right. Exactly. Which is why some systems that need to keep time reliably, or 
that integrate frequency to get time, avoid leap seconds altogether.

/tvb

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

Re: [LEAPSECS] Set your alarms for 2.40am UTC -Brooks

[Tom Van Baak]

See also:

https://www.febo.com/pipermail/time-nuts/2017-July/106316.html

/tvb

- Original Message - 
From: "Brooks Harris" 
To: "Leap Second Discussion List" 
Sent: Thursday, July 13, 2017 1:07 PM
Subject: [LEAPSECS] Set your alarms for 2.40am UTC -Brooks


Set your alarms for 2.40am UTC – so you can watch Unix time hit 
1,500,000,000
It's gonna be spectacular!
https://www.theregister.co.uk/2017/07/13/unix_timestamp_epoch_making_moment/
-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] Negative TAI-UTC

[Tom Van Baak]

Hi Clive,

Ok, that's my kind of programmer!

Then use 8 bits. That gives you one for sign and 7 for magnitude. We've had +27 
leap seconds (6-bits) in 45 years so you're well within the +/- 127 limit for 
the rest of the century. If your project specs call for a greater lifetime than 
that then add a massive safety margin and go with 10 bits. If your project does 
not need to handle times prior to the present, then you can save a few bits by 
using the year 2000 or 2016 as the origin instead of 1972.

/tvb

- Original Message - 
From: "Clive D.W. Feather" <cl...@davros.org>
To: "Tom Van Baak" <t...@leapsecond.com>; "Leap Second Discussion List" 
<leapsecs@leapsecond.com>
Sent: Tuesday, February 07, 2017 9:40 AM
Subject: Re: [LEAPSECS] Negative TAI-UTC


> Tom Van Baak said:
>> Yes, of course. This is not the 1960's where saving a byte was an all-day 
>> decision. The spec is clear. Follow it.
> 
> Actually, some of us work in fields where every byte is still expensive.
> 
> -- 
> Clive D.W. Feather  | If you lie to the compiler,
> Email: cl...@davros.org | it will get its revenge.
> Web: http://www.davros.org  |   - Henry Spencer
> Mobile: +44 7973 377646
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] BBC radio Crowd Science

[Tom Van Baak]

> 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?

Correct.

> 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.

I can't speak for the "several ways" and the subtle trouble they cause. But...

GPS is one example of how to do it right. You start with a non-leap time scale 
like GPS system time. You then maintain not 1, not 2, but 3 values: old offset 
/ transition date / new offset. That way, for any second you can generate a 
correct GPS time stamp or a correct UTC time stamp. The goal is to generate a 
time stamp. This also avoids the artificial worry about Bulletin C wording or 
the definition of "offset" or whatever else this thread has turned into. 

> 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?

There's no TAI-UTC metadata output. A typical GPS receiver outputs:

1) an digital pulse whose rising edge is closely aligned with either the GPS or 
TAI/UTC second, aka 1PPS.

2) a stream of binary or ascii packets, one or more of which contain a time 
stamp. Depending on user choice, the time stamp may be GPS time, or it may be 
UTC time. Depending on make / model, the time stamp may refer to the 1PPS that 
just occurred, or the 1PPS that will occur next.

That's all. It's very simple. I've never heard anyone remotely confused about 
the beginning, middle or end of a leap second. Again, there are precise pulses 
and there are date/time labels for those pulses.

> 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.

If you're building a receiver *and* generator you need more than a single field 
named currentUtcOffset. Or maybe I don't quite understand what 
timePropertiesDS.currentUtcOffset actually means or how it's intended to be 
used in bi-directional conversion.

Let's settle this part of your question first, before we go on to talk about 
how GPS/GNSS receivers can or can't be used to mimic leap second tables.

/tvb

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

Re: [LEAPSECS] BBC radio Crowd Science

[Tom Van Baak]

> 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.

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. To get TAI one just adds 19 to GPS time. So 
no worries either way.

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.

> 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

Re: [LEAPSECS] BBC radio Crowd Science

[Tom Van Baak]

> Also, I'll note that bulletin C says from 0h, which is a time
> expressed to only one significant digit.

That's a lame excuse to bring up significant digits.
Everyone knows that "0h" means midnight, the one at 00:00:00 (as opposed to the 
one at 24:00:00).
Are you now going to criticize a UTC(k) lab for writing 23:59:60 when we really 
mean 23:59:60.0?

/tvb

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

Re: [LEAPSECS] Negative TAI-UTC

[Tom Van Baak]

Yes, of course. This is not the 1960's where saving a byte was an all-day 
decision. The spec is clear. Follow it.

While there's sufficient evidence the earth is slowing down over astronomical 
time due to tidal forces, it's also quite clear that the earth has been 
speeding up over the past 30 years. Therefore another ~7 year lull and even a 
negative leap second is likely within 10 to 20 years. And if that trend were to 
continue, then TAI-UTC will max out and head back down, to 37, to 10, to 0, and 
negative. All depending on how long this temporary speeding up lasts, of 
course. Or what happens with global warming.

So code and data structures must handle all cases of positive and negative leap 
second, as well as all cases of large and small, positive and negative TAI-UTC. 
Do it for the exercise, or as a robust example, if nothing else. To paraphrase 
Henry Spencer (see below) if you lie to a time scale it will get revenge.

/tvb

- Original Message - 
From: "Clive D.W. Feather" 
To: "Leap Second Discussion List" 
Sent: Saturday, February 04, 2017 8:41 AM
Subject: [LEAPSECS] Negative TAI-UTC


> 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?
> 
> -- 
> Clive D.W. Feather  | If you lie to the compiler,
> Email: cl...@davros.org | it will get its revenge.
> Web: http://www.davros.org  |   - Henry Spencer
> Mobile: +44 7973 377646

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

Re: [LEAPSECS] BBC radio Crowd Science

[Tom Van Baak]

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

- Original Message - 
From: "Warner Losh" 
To: "Leap Second Discussion List" 
Sent: Friday, February 03, 2017 1:30 PM
Subject: Re: [LEAPSECS] BBC radio Crowd Science


> 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:60

Re: [LEAPSECS] BBC radio Crowd Science

[Tom Van Baak]

Here's a different take on the situation. Or maybe it's just how someone with 
cesium clocks looks at the problem. Don't over think what I mean by "clock", 
"user" and leap second "table" below.

Timescale / timestamp conversion in Six Easy Cases:

1) clock sends UTC, user wants UTC

- N.B. clock needs table in order to maintain UTC.

2) clock sends UTC, user wants TAI

- N.B. clock needs table in order to maintain UTC.
- User needs table and utc_to_tai() conversion.

3) clock sends UTC and +N, user wants TAI

- N.B. clock needs table in order to maintain UTC.
- User does not need table.
- User does radix-60 math on UTC timestamp + N to get TAI timestamp.
- Clock is careful to send the right N near negative and positive leap seconds.

4) clock sends TAI, user wants TAI

- N.B. neither clock nor user needs table.

5) clock sends TAI, user wants UTC

- N.B. clock does not need table.
- User needs table and tai_to_utc() conversion.

6) clock sends TAI and -N, user wants UTC

- N.B. clock needs table in order to maintain N.
- 6x) User finds that TAI and N is *insufficient* to generate UTC timestamp (in 
the case of a positive leap second).
- Therefore user needs table as in case 5 above -- and essentially ignores N, or
- 6a) clock must send N1 and N2 so that user can generate UTC in all cases, or
- 6b) clock must send N and F (e.g., positive leap flag) so user can generate 
UTC correctly, or
- 6c) clock must send N and R (e.g., radix 60 or 61) so user can generate UTC 
correctly.

--

How does this relate to our discussion? We often see "equations" like:

   TAI = UTC + (TAI-UTC)   or   UTC = TAI + (UTC-TAI)

and it's not clear if it's a succinct statement about time scale offset or a 
recipe for time stamp conversion. We'd like to think they are exactly 
equivalent, as one finds in mathematical equations (but they are not equations).

The former expression, TAI = UTC + (TAI-UTC), looks very much like case 3 
above, where N = TAI-UTC. There's no problem with case 3. N is clean and 
simple: 36 in 2016 (including the leap) and 37 in 2017.

The latter expression, UTC = TAI + (UTC-TAI), is unfortunately more like case 6 
above, where N = UTC-TAU. And since case 6x is useless, one must actually 
implement case 6a or 6b or 6c instead:

If you stick with case 6x, you will encounter contradictions and may resort to 
blaming the wording of Bulletin C (several).

If you do a table lookup and peek ahead and behind to get N1 and N2, then it's 
like case 6a (Steve).

If you do a table lookup and find the timestamp is a leap second and flag it, 
then it's like case 6b (Brooks).

If you do a table lookup and call your leap second flag a variable radix, then 
it's like case 6c (Warner).

/tvb

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

Re: [LEAPSECS] BBC radio Crowd Science

[Tom Van Baak]

> It's tricky.

Yes.

> Bulletin C is pretty clear about when it thinks TAI-UTC changes:

Yes.

> However, since there isn't any TAI time with a :60 seconds label,

Yes.

> it doesn't make much sense to have a defined delta for the last UTC second of 
> 2016.

No.

The delta is defined "until further notice". Therefore the delta is defined 
just fine during all of 2016, including *during* the positive leap second. The 
delta changes only as of 1-Jan-2017 UTC, which is why there is a leap second in 
the first place. In other words, the change in delta is what *causes* the leap 
second to exist. This works fine for both positive (-1 change in delta) and 
negative leap seconds (+1 change in delta).

Another way to look at it is imagine in the distant future if we needed 3 or 5 
or 20 leap seconds every month. The delta would still change by an integer but 
it would be greater than 1. There would be several positive leap seconds on 
that last day, 23:59:60, 23:59:61, 23:59:62. This does not mean time changes 
slowly. This does not mean the delta is undefined. It means the delta this 
month and the delta next month *are* precisely defined and this alone is what 
creates the addition or subtraction of multiple seconds in the last UTC minute 
of the month. A conventional leap second table has all the information you need 
to accomplish this and there is no problem in perfectly mapping TAI to UTC to 
TAI in all cases.

So I see no reason or need to pick on "delta" as being in an indeterminate 
state during a leap second. We have enough exceptions with leap second handling 
as it is. Let's not create more confusion.

/tvb

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

Re: [LEAPSECS] BBC radio Crowd Science

[Tom Van Baak]

> TAI is the fundamental time scale, with UTC derived from it.  As TAI
> advances, you can calculate UTC by subtracting TAI-UTC from it.  At TAI
> = 34 seconds, TAI-UTC is 35 and the corresponding UTC time is 23:59:59.
> That can be arithmetically correct only if you don't count the leap
> second, so let's not count it.

That sounds dangerous. There's a one-to-one mapping between valid UTC 
timestamps and valid TAI timestamps. Yes, you need a table to do the mapping, 
but the mapping is unambiguous (for recent and near future times).


> When the TAI time is 35 seconds, you would think the UTC time would be
> 0 seconds, but because of the leap second it is 23:59:60.  Thus, the
> value of TAI-UTC doesn't tell you everything you need to know to
> convert from TAI to UTC: you also have to know that there is a leap
> second in progress.

Huh? No, that doesn't sound right at all.

If your TAI-UTC table and code are correct, then every valid UTC timestamp has 
a TAI equivalent and vice versa. What is *invalid* is a 23:59:59 UTC timestamp 
(negative leap) or a 23:59:60 UTC timestamp (positive leap) that is not 
prescribed by the table.

A conversion from UTC to TAI will catch these errors and a conversion from TAI 
to UTC will not generate these errors. Also, any timestamp with hours<0 or 
hours>=24 or minutes<0 or minutes>=60 is invalid, without even looking at the 
table.

For this, it's best not to think of "a leap second" as in progress or as a 
duration; otherwise you may give preferential treatment to positive leap 
seconds only, or make special cases for one over the other. Instead think of a 
leap second as an *event* that forces a table lookup of how long that day is.


> I had thought that TAI-UTC was the only information needed to convert
> from TAI to UTC, and therefore that it could not be a step function
> because of positive leap seconds.  I see now that I was mistaken.  Is
> my new belief correct that you need both TAI-UTC and the knowledge that
> a leap second is in progress to convert from TAI to UTC?

Hmm, it sounds like your new belief is wrong too. That's why I suggested 
writing tests for your library; so you could catch these errors yourself. The 
table is all you need to decide how to convert between TAI/UTC and UTC/TAI. 
Yes, the code gets tricky near +/- N seconds of midnight, where N is |TAI-UTC|.

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

Re: [LEAPSECS] BBC radio Crowd Science

[Tom Van Baak]

> but I've always thought the
> instant of the change was unambiguous, and that it was
> instantaneous in both cases.

Correct.

> I've only shown half-second increments, but in the limit, in the
> positive case, TAI-UTC would be precisely 35 for every instant of
> the second numbered 60, and changes to 36 at the first instant of
> 00:00:00 UTC.  Similarly, in the negative case, it's 35 for all
> of 23:59:58, and again changes at the first instant of 00:00:00.

Correct. And the fraction- or half-second technique is useful to illustrate 
this.

> (For me this
> helps explain the oddity that leap second tables typically list
> the days *after* what feels like the leap second days: the tables
> list the first instant of each new TAI-UTC value, which ends up
> being the instant after the "essential discontinuity".)

Yes, I've thought the same.

There is a wide variety of leap second table formats; in print, on the web, and 
in code. A good number encode the end of the month date (e.g., 6/30) and a good 
number encode the beginning of the month date (e.g., 7/1). At one level it 
doesn't really matter. But there are often subtle user-interface or programming 
or testing reason to choose one over the other. I used to have strong 
preferences, but now I more appreciate the extent of programmer creativity.

Lookup tables that just deal with UTC leap seconds tend to use the 6/30 format. 
Tables that work with TAI and UTC or TAI-UTC tend to use the 7/1 format. Tables 
that were designed with positive leap seconds on the brain are more likely to 
use the 6/30 format.

Given when leap seconds happen local time, those of US in the far west tend to 
think of leap seconds happening in 6/30 format while those from Paris to the 
far east tend to think of leap seconds happening in 7/1 format. Index-1 
programmers (e.g., FORTRAN) may unconsciously use <=, or 6/30 format, while 
index-0 programmers (C) may think of <, or 7/1 format.

Some tables encode if the leap is +1 or if the leap is -1. Some encode the 
length of the minute (59, 61). Some encode the length of the day (86399, 86400, 
86401). Some tables use year and month only, some use year, month and day 
(redundant), some use MJD, some use JD, some use unix time_t, some use NTP 
time, some use GPS time.

So there's a wide variety of formats. I'm working on a "best practices" 
document with a pile of examples of how it's done, and how to do it right. 
Also, lots of embarrassing examples from the web of how it's done wrong.

/tvb

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

Re: [LEAPSECS] BBC radio Crowd Science

[Tom Van Baak]

> Based on the definition of UTC, it seems to me that there are two
> cases, both of which are very simple.  For a negative leap second, the
> change in TAI - UTC happens instantly at UTC midnight, which is one
> second after 23:59:58, when the difference changes by -1.  For a
> positive leap second, the change happens gradually over the time of the
> leap second, from 23:59:60 to midnight, when the difference slowly
> changes by +1.

No, that's not how leap seconds work. Do you have a reference for this idea, or 
did you just make it up.

The signed integer TAI-UTC is a step function. The step occurs between the end 
of one month and the beginning of the next. Tables that encode these steps only 
need one entry per leap.

UTC flows constantly one SI second at a time. Every second has the same billion 
nanoseconds. You either delete a label (23:59:59) or add a label (23:59:60) but 
there is no fast or slow about it. It sounds like you are confusing UTC with 
leap smearing, but I know you better than that.

/tvb

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

[LEAPSECS] seconde intercalaire

[Tom Van Baak]

An alert reader sent me this note. I have not independently confirmed it.
/tvb



On December 31, 2016, in Montreal Québec, the municipal police/FD radio
communications went into a total shutdown for over 55 minutes. 

The $74 million digital-encrypted SERAM radio communications system developed
by Airbus DS suddenly went down preventing communications between the 9-1-1
central dispatch and patrolmen on the field.

After investigation, the problem has been finally found: the system engineers
forgot to take into account the "unexpected" leap second that occurred on
Dec 31 2016 at 23:59:60 

Source (in French):
http://www.tvanouvelles.ca/2017/01/04/exclusif--faille-de-securite-majeure-au-nouvel-an



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

Re: [LEAPSECS] LEAPSECS Digest, Vol 124, Issue 17

[Tom Van Baak]

> Feb 29th, of course.  The print macro just adds "10" to the year field. :-)

What would be worse is if Hal worked there 40 years before he got a 10th 
anniversary certificate.

/tvb

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

Re: [LEAPSECS] LEAPSECS Digest, Vol 124, Issue 17

[Tom Van Baak]

> I started work at DEC on Feb 29th.  10 years later, I got a fancy certificate 
> congratulating me on being there for 10 years.  Want to guess what date was 
> on it?

Ha! This from the same company that in 1983 wrote my favorite bug report of all 
time:

https://h41379.www4.hpe.com/openvms/products/year-2000/leap.html

/tvb

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

Re: [LEAPSECS] alternative to smearing

[Tom Van Baak]

Oops; typo; sorry; I'm an idiot by a factor of millions. s/seconds/years/ and 
it should read:

9) Exposing citizens to leap days is near universal. Printed and computer 
calendars have no trouble with that extra day. Almost every child learns about 
leap years during their schooling. Some people are even born on a leap day.

/tvb
www.leapsecond.com (or, wait, should that be leap year dot com)

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

Re: [LEAPSECS] alternative to smearing

[Tom Van Baak]

> There's a big difference between these two: February varies in a fixed,
> regular manner, whereas UTC days are unpredictable.  The Gregorian
> calendar is of the arithmetic variety, whereas UTC is an observational
> calendar.  UTC is qualitatively more difficult to handle.
> 
> -zefram

Agreed. The February leap day is a useful analogy when describing leap seconds 
to non-technical people. But when you get into the details the two are vastly 
different. For the newcomers to the list...

1) The leap day in February can be handled by any isolated or autonomous clock 
or timekeeping system. A leap second can only be handled with periodic direct 
or indirect communication with IERS, or manual intervention with the likes of 
keyboard input or toggle switches. For secure or embedded systems this is a 
huge issue.

2) Past dates involving February can be handled with arithmetic. Past leap 
seconds are handled with leap second tables.

3) Future dates involving February pose no additional computing challenge. 
Future dates with leap seconds beyond a few months are simply not possible, or 
possible only with error bars.

4) Code to validate arbitrary time stamps involving February is trivial. 
Validating time stamps involving leap seconds is possible only if code or 
tables are updated frequently. And this applies to every layer in the sometimes 
massive stack from h/w to end-user interface.

5) Proleptic calculations involving February are static. Proleptic calculations 
involving leap seconds will differ from author to author and will change as new 
historical research on past earth rotation evolves.

6) February leaps are binary (28 or 29). Leap seconds have three states 59, 60, 
61. Actually, it's 4-state monthly: not-known-yet, known to be 59, known to be 
60, known to be 61.

7a) The leap in February allows fine tuning of the stable ratio of earth 
revolution to earth rotation. What is at stake is the alignment of the calendar 
vs. seasons.

It would take an error in the leap day count of, say, 5 to 10 days before it 
would be noticeable to people. The worst-case would be 183 days but obviously 
no one will let that happen.

7b) A leap second allows fine tuning of the unstable ratio of earth rotation to 
SI second. What is at stake is the alignment of time-of-day vs. noon (in 
Greenwich). Because most people don't live in Greenwich a system of ~24 hourly 
time zones exists to move 12 o'clock closer toward noon and thus nominally 
limit the error to +/- 0.5 hours. However for practical, geographical and 
political reasons this actual level of error is much larger for many people. 
Latitude plays a role. Daylight saving time has a role. Also noon wanders by as 
much as half an hour on its own (equation of time).

All factors considered, it would take an error in the leap second count of, 
say, 1000 to 3000 seconds before it would be noticeable to people. The 
worst-case would be 43200 seconds but obviously no one will let that happen.

8) Both of the above ratios are determined by nature. If / when the existing 
leap day system breaks down, one can simply add or delete N days from a chosen 
year, as was done by the Gregorian calendar reform. It's not pleasant but it 
worked. It may be required on the order of several thousand years, depending on 
N.

If / when the existing leap second system breaks down, one can simply add or 
delete N seconds from a chosen day. It also would not be pleasant but it would 
work. Or one can use the existing noon-alignment knob (time zones) to keep noon 
at 12. It may be required on the order of several thousand years, depending on 
N.

9) Exposing citizens to leap days is near universal. Printed and computer 
calendars have no trouble with that extra day. Almost every child learns about 
leap seconds during their schooling. Some people are even born on a leap day.

Exposing citizens to leap seconds is neither universal nor required. No analog 
representation of time can cope with 61 seconds, and even most digital clocks 
do not. Children are not taught about leap seconds. In fact few physicists, 
engineers, and programmers understand them either.



I mention all this not to be pro- or con- leap second, but to explain that the 
February leap day analogy is both useful and dangerously misleading. One 
requires a single sentence of explanation and one or three lines of code. The 
other requires a massive, complex and confusing, world-wide measurement and 
communication infrastructure.

/tvb

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

Re: [LEAPSECS] Leap seconds ain't broken

[Tom Van Baak]

> There are subtleties to timekeeping. Removing leap seconds wouldn’t remove 
> the subtleties, rather it would promote them to significantly more 
> importance, perhaps “breaking” even more software and systems.
> 
> Rob 

Now that several dominate vendors of computing are using smeared leap seconds, 
what problem will it cause that they are still calling it UTC? I suspect there 
will be platforms saying this is UTC and thinking it's UTC, when it really 
isn't. Do they provide an API to find out if you're getting the real, original, 
chunky UTC or the new, smooth, creamy version. The sysadmin may know because 
they configured the NTP server; but does the user or any apps know?

Ok, it's only a half second of error, over a day, once every few years. But 
that sort of bizarre exception is still a headache for testing. Moreover, now 
leap second QA tests will take 20 or 24 hours instead of 2 minutes.

That reminds me. I don't suppose we could get google, et al. to rename it UTX 
instead of UTC? And should the UTX label apply always, or just during the -12 
to +12 hours around the leap? If the latter, it would make it very convenient 
to convert UTX timestamps to UTC timestamps and vise versa.

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

[LEAPSECS] JD & MJD, UT1 & UTC

[Tom Van Baak]

Now is a good a time as any to bring up an issue I've been meaning to ask.

My understanding is that JD has always been a day count, based on rotations of 
the earth. So the timescale from which JD is calculated is UT1 (not TAI or 
UTC). JD is widely used in astronomy. Presumably when JD is calculated from UTC 
one applies a DUT1 correction.

The textbook definition of MJD is simply JD - 240.5, which implies it is 
also based on UT1. But MJD is widely used in time metrology and in this context 
it is based on UTC, not UT1. Almost every report, graph, database and table you 
see from a timing laboratory uses MJD. There's a massive amount of code that 
takes UTC, does some arithmetic, divides by 86400.0 and out comes MJD.

A side-effect of this is that there is no valid MJD representation for the leap 
second we had a few days ago. I think most people sweep this under the rug and 
move on. For example, when making plots with MJD the error or ambiguity caused 
by a leap second is far less than one pixel and nobody notices.

But since some of you are real picky about formal definitions, my question is 
what to do about MJD -- is it UT1-based or it is UTC-based? And if UTC-based, 
what's the right thing to do when the day has a +/- leap second?

And if leap seconds were to vanish, would MJD become UTC-based instead of 
UT1-based? Would metrology and astronomy fight over who gets to define the 
timescale of MJD?

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

Re: [LEAPSECS] Greetings from an intercalary second

[Tom Van Baak]

Line 55 of my raw headers has your leap second:

1 Return-Path: 
2 Delivered-To: tvb-leapsecond:com-...@leapsecond.com
3 X-Envelope-To: t...@leapsecond.com
4 Received: (qmail 73506 invoked from network); 1 Jan 2017 00:00:09 -
...
00049  for ; Sat, 31 Dec 2016 19:00:05 -0500 (EST)
00050 Received: from shellx.eskimo.com (shellx.eskimo.com [204.122.16.2])
00051  by mail.eskimo.com (Postfix) with ESMTP id BF13B22D3;
00052  Sat, 31 Dec 2016 16:00:03 -0800 (PST)
00053 Received: by shellx.eskimo.com (Postfix, from userid 10926)
00054  id B432739F7; Sat, 31 Dec 2016 16:00:03 -0800 (PST)
00055 Date: Sat, 31 Dec 2016 18:59:60 -0500
00056 From: scs...@eskimo.com (Steve Summit)
00057 To: leapsecs@leapsecond.com
00058 Message-Id: <2017010103.b43273...@shellx.eskimo.com>
00059 X-Virus-Scanned: clamav-milter 0.99.2 at mail.eskimo.com
00060 X-Virus-Status: Clean
00061 Subject: [LEAPSECS] Greetings from an intercalary second
...
00078 Sender: "LEAPSECS" 
00079 
00080 Some readers may be interested in the Date: line on this message.
00081 It is not faked: it was added by a lightly-modified sendmail
00082 program running under a Linux kernel keeping true UTC, with the
00083 timestamp fetched via clock_gettime(CLOCK_UTC) and formatted
00084 using a timespec-aware version of localtime().
00085 
00086 I don't claim that the code behind this demonstration solves every
00087 leapsecond-related difficulty (far from it!), but it's a start.
00088 ___
00089 LEAPSECS mailing list
00090 LEAPSECS@leapsecond.com
00091 https://pairlist6.pair.net/mailman/listinfo/leapsecs

/tvb

- Original Message - 
From: "Steve Summit" 
To: 
Sent: Saturday, December 31, 2016 3:59 PM
Subject: [LEAPSECS] Greetings from an intercalary second


> Some readers may be interested in the Date: line on this message.
> It is not faked: it was added by a lightly-modified sendmail
> program running under a Linux kernel keeping true UTC, with the
> timestamp fetched via clock_gettime(CLOCK_UTC) and formatted
> using a timespec-aware version of localtime().
> 
> I don't claim that the code behind this demonstration solves every
> leapsecond-related difficulty (far from it!), but it's a start.
> ___
> 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] Time math libraries, UTC to TAI

[Tom Van Baak]

Eric, and time nuts -- A very nice set of questions and an interesting 
application. In fact it's so time nutty that I'll send it over to the LEAPSECS 
mailing list, which is the niche of time-nuts where we deal with issues of TAI, 
UTC and leap seconds. You can pick up your replies there.

LEAPSECS -- please help Eric out. I suspect there are good answers ranging from 
bloated universal date/time packages to one page of elegant code.

Thanks,
/tvb

- Original Message - 
From: "Eric Scace" 
To: "Discussion of precise time and frequency measurement" 
Sent: Tuesday, December 13, 2016 5:50 AM
Subject: Re: [time-nuts] Time math libraries


   I should clarify my intended application for "time math".

   My company is deep in development of a system that, in part, records events 
on a blockchain. For various reasons a precise and accurate representation of 
time of the event can be important. How precise and accurate depends on the 
application. The first applications need millisecond precision and tens of 
millisecond accuracy - not a huge demand by TimeNut standards, but not to be 
neglected. Leap seconds (and the differing contortions being used by various 
organizations to evade implementation of leap seconds) should not be ignored.

   The blockchain runs as a generic event-recording ledger utility supporting 
many applications. Over time, we will need to get more precise and accurate on 
time.

   To be general, we take the following approach:
Timestamp (and, often, geolocation) are acquired at the point of measurement 
for the data set. This is treated as the opinion of the collecting device. We 
record meta-data about the collecting device. For some applications the 
meta-data includes information as to how the device formed its opinion of time.
The application submits the event to the ledger service's API for recording.
The API server(s) timestamp the client's request to record to the ledger. This 
timestamp is relatively important because it is the declaration of the ledger, 
an immutable reference of the sequence of events, upon which other systems will 
rely in future.

   The present scheme is to use TAI as the timescale for all events recorded to 
the ledger. Some of the implications:
Collecting device timestamps may need to be convertible to TAI.
This task can be a mess, because the sources of time opinions may be vast; 
e.g., cell phones, AWS, Google, MS Azure, etc. We work around this by capturing 
meta-data about the device's timescale and source. This allows retrospective 
consideration of the devices' time opinion relative to TAI when it is important 
for the downstream data consumer.
Independent systems participating in the blockchain (e.g., as API server, or as 
consensus-forming systems) should have consistent opinions of TAI.
Ledger timestamps (in TAI) need to be converted to the data consumer's desired 
time scale.
Here's another instance of the need for a set of time math utilities.

   I realize this description also opens a Pandora's box that involves 
distribution of time issues. But, for the purposes of this thread, I wanted to 
focus on the TAI-to-other-timescales conversion utility question.

   If good timescale conversion utilities exist, we would use them.

   If good timescale conversion utilities do not exist, then maybe we'll 
contribute one to the open software space.

- Eric

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

[LEAPSECS] private smear goes public

[Tom Van Baak]

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

Re: [LEAPSECS] A standard for leap second smearing

[Tom Van Baak]

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

Re: [LEAPSECS] Bloomberg announced its smear

[Tom Van Baak]

Harlan,

Get down to the details about PC clock frequency instability and OS measurement 
jitter and I suspect you'll find that cosine vs. triangle is a red herring.

I would almost vote for random smear. The purpose of a smear is to obscure the 
extra / missing second in UTC. If someone downstream wants to know *how you 
implemented the smear* you have already lost the battle. It means they secretly 
want to know real UTC instead of accepting your smeared UTC. This is a problem. 
Smearing is for clients that don't care about the arcane details of UTC, or 
about sub-second accuracy, but maybe still want a monotonic clock that's pretty 
close to UTC and the SI second most of the time.

/tvb

- Original Message - 
From: "Harlan Stenn" 
To: "Leap Second Discussion List" 
Sent: Wednesday, September 28, 2016 5:24 AM
Subject: Re: [LEAPSECS] Bloomberg announced its smear


> Martin,
> 
> Cosine smearing might need to be a choice.  It's harder to track the
> leap second if you get a sample during when both phase and frequency are
> changing.
> 
> -- 
> Harlan Stenn 
> http://networktimefoundation.org  - be a member!

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

Re: [LEAPSECS] Bloomberg announced its smear

[Tom Van Baak]

> Hm, IMO the advantage of the initial smear approach (24 hours before the
> leap second) is that smearing is finished as soon as the leap second has
> occurred, so the beginning of the next UTC day /hour / minute is accurate.

Martin,

I suspect your idea only works in cases when the time server is instantaneously 
jamming time to a stateless client. But there is often some level of filtering 
and so the client will necessarily lag the server. In this case the client will 
not have accurate UTC until many time constants after midnight.

/tvb

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

Re: [LEAPSECS] A standard for leap second smearing

[Tom Van Baak]

> Does it matter that in Seattle the smear occurs at 5:00 in the afternoon, 
> local time,

Richard,

When using local time, it's one step more complicated; in Seattle:
  4:00 PM PST is when a leap second occurs in Winter (e.g., December 31)
  5:00 PM PDT is when a leap second occurs in Summer (e.g., June 30)

/tvb

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

Re: [LEAPSECS] Bloomberg announced its smear

[Tom Van Baak]

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

Re: [LEAPSECS] Bloomberg announced its smear

[Tom Van Baak]

Stephen,

> As I've been saying for years, what we need (desperately) is a
> standard for smearing, aka 86400 subdivision days.

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.

> 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.

/tvb

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

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

[Tom Van Baak]

> The data format only has a "leap second pending flag", which means a
> leap second is to be inserted.

Hi Martin,

Ouch. Well that's a problem. LSEM aside, what are you going to do if the earth 
continues to gradually speed up as it has the past couple of decades?

If you look at the WWVB spec, it also has a single bit for leap second pending. 
So at first glance it would appear to have the same problem as DCF77. But WWVB 
has bits for DUT1; the sign bit of DUT1 effectively tells you if the pending 
leap second is insert or delete.

/tvb

- Original Message - 
From: "Martin Burnicki" <martin.burni...@burnicki.net>
To: "Tom Van Baak" <t...@leapsecond.com>; "Leap Second Discussion List" 
<leapsecs@leapsecond.com>; "Discussion of precise time and frequency 
measurement" <time-n...@febo.com>
Sent: Friday, July 22, 2016 1:44 AM
Subject: Re: [LEAPSECS] [time-nuts] Leap second to be introduced at midnight 
UTC December 31 this year


> Tom Van Baak wrote:
>> Time to mention this again...
>> 
>> If we adopted the LSEM (Leap Second Every Month) model then none of
>> this would be a problem. The idea is not to decide *if* there will be
>> leap second, but to force every month to have a leap second. The IERS
>> decision is then what the *sign* of the leap second should be this
>> month.
> 
> Although this approach sound good, it would cause major problems for
> users of the German longwave transmitter DCF-77. The data format only
> has a "leap second pending flag", which means a leap second is to be
> inserted. AFAIK there is no spec to announce a negative leap second via
> DCF-77.
> 
> Martin
>
___
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

[Tom Van Baak]

Hi Tom,

> Does your proposal allow for a Zero leap second

Nope, LSEM avoids the zero leap second situation. That's the idea: to always 
have a leap second. Either an add or a delete, at the end of every month. The 
beauty is that it wouldn't violate how UTC is already defined. Leap seconds 
would become a monthly normal instead of a rare event; that is, a regular pain 
in the ass instead of an exceptional pain in the ass [1].

Note that UTC would continue to stay within a second of UT1, so no problems 
there either. If you think about it, LSEM, like any fast dithering system, 
would actually create a better average value of UT1 than the existing slow step 
system. But that's not a goal; just a PWM side-effect.

There's more info in the original LSEM proposal and its long thread in the 
archives:

http://six.pairlist.net/pipermail/leapsecs/2010-November/001813.html


> Might also cause less consternation for some services, like the finance and
> scientific worlds, that seem to have critical issues when an LS appears.

add to your list: airplanes, high-speed trains, telesurgery, self-driving cars, 
MRI machines ...

Yes, and that's the key question. And it's only getting worse. LSEM is not a 
random idea or a quick fix. As long as UTC has leap seconds (debatable) or as 
long as technology continues to depend on ever more precise time (likely) we 
have to make the handling of leap seconds as robust as the handling of, say, 
midnight rollover.

I realize it's probably too late in history to deploy. There's no right answer. 
LSEM is food for thought. Lots of people are and have been trying to avoid the 
long-term train wreck that the current definition and implementation of UTC 
will lead to. If you have time, read 15 years of our postings over on the leap 
second mailing list.

I think at this point, we should move the thread over to LEAPSECS alone, and 
give time-nuts a break. The cross-posting is getting confusing.

Thanks,
/tvb

[1] astronomical society specification ;-)


- Original Message - 
From: "Tom Holmes" <thol...@woh.rr.com>
To: "'Discussion of precise time and frequency measurement'" 
<time-n...@febo.com>
Cc: "'Leap Second Discussion List'" <leapsecs@leapsecond.com>
Sent: Thursday, July 21, 2016 12:03 PM
Subject: Re: [time-nuts] Leap second to be introduced at midnightUTC December 
31 this year


> Hi Tom...
> 
> Does your proposal allow for a Zero leap second, or does it require either 
> plus or minus 1 to work? Seems like you could stay closer to the true value 
> if you also have a zero option. Might also cause less consternation for some 
> services, like the finance and scientific worlds, that seem to have critical 
> issues when an LS appears.
> 
> I like your point that by having it occur monthly it forces systems to 
> address issues promptly, and maybe that's the argument for the non-zero 
> option.
> 
> Tom Holmes, N8ZM
> 
> 
> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Tom Van Baak
> Sent: Thursday, July 21, 2016 1:28 PM
> To: Discussion of precise time and frequency measurement <time-n...@febo.com>
> Cc: Leap Second Discussion List <leapsecs@leapsecond.com>
> Subject: Re: [time-nuts] Leap second to be introduced at midnight UTC 
> December 31 this year
> 
> Time to mention this again...
> 
> If we adopted the LSEM (Leap Second Every Month) model then none of this 
> would be a problem. The idea is not to decide *if* there will be leap second, 
> but to force every month to have a leap second. The IERS decision is then 
> what the *sign* of the leap second should be this month.
> 
> Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with UTC, 
> not so much by rare steps but by dithering. There would be no change to UTC 
> or timing infrastructure because the definition of UTC already allows for 
> positive or negative leap seconds in any given month.
> 
> Every UTC-aware device would 1) know how to reliably insert or delete a leap 
> second, because bugs would be found by developers within a month or two, not 
> by end-users years or decades in the future, and 2) every UTC-aware device 
> would have an often tested direct or indirect path to IERS to know what the 
> sign of the leap second will be for the current month.
> 
> The leap second would then become a normal part of UTC, a regular monthly 
> event, instead of a rare, newsworthy exception. None of the weird bugs we 
> continue to see year after year in leap second handling by NTP and OS's and 
> GPS receiver firmware would occur.
> 
> Historical leap second tables would consist of little more than 12 bits per 
> year.
> 
> Moreover, in the next decade or two or three, if we slide into an era where 
> average earth rotation sl

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

[Tom Van Baak]

Steve Allen wrote:
> This idea pushes extra complexity into every implementation of low
> level kernel-space software, firmware, and hardware.  That's nice as a
> policy for full employment of programmers, but it's hard to justify by
> any other metric.  Instead those low level places should be as simple
> as possible, and that means making the underlying precision time
> scale, and thus any broadcast distributions of a precision time scale,
> as simple as possible.
> 
> The complexity for translating precision time in seconds (for
> machines) to calendar time in days (for humans) belongs in the
> less-critical and easier-testable outer layers of software which do
> user-space presentation, internationalization, and GUI which can be
> broadly shared between many hardware implementations.

Hi Steve,

Wow, that's most succinct two paragraph argument I've read for why we shouldn't 
have leap seconds at all. Where were you the past decade when this level of 
passion and clarity in the ITU debate was needed ;-)

/tvb
___
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

[Tom Van Baak]

Time to mention this again...

If we adopted the LSEM (Leap Second Every Month) model then none of this would 
be a problem. The idea is not to decide *if* there will be leap second, but to 
force every month to have a leap second. The IERS decision is then what the 
*sign* of the leap second should be this month.

Note this would keep |DUT1| < 1 s as now. UT1 would stay in sync with UTC, not 
so much by rare steps but by dithering. There would be no change to UTC or 
timing infrastructure because the definition of UTC already allows for positive 
or negative leap seconds in any given month.

Every UTC-aware device would 1) know how to reliably insert or delete a leap 
second, because bugs would be found by developers within a month or two, not by 
end-users years or decades in the future, and 2) every UTC-aware device would 
have an often tested direct or indirect path to IERS to know what the sign of 
the leap second will be for the current month.

The leap second would then become a normal part of UTC, a regular monthly 
event, instead of a rare, newsworthy exception. None of the weird bugs we 
continue to see year after year in leap second handling by NTP and OS's and GPS 
receiver firmware would occur.

Historical leap second tables would consist of little more than 12 bits per 
year.

Moreover, in the next decade or two or three, if we slide into an era where 
average earth rotation slows from 86400.1 to 86400.0 to 86399.9 seconds a day, 
there will be zero impact if LSEM is already in place.

/tvb

___
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

[Tom Van Baak]

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.

We typically reserve the word leap second "pending" for the month in which the 
leap second will actually occur. 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.

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. 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.

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 ever hardcode this assumption.

There's also a less common belief that a leap second may occur at the end of 
March, June, September, or December. This is also false. Don't hardcode this 
either.

IERS is free to schedule a leap second at the end of any month. And it may be 
an insert or a delete. Assume nothing more or less in your code. Code and test 
and document for positive and negative leap seconds equally.

I say this because with the gradual warming / melting of the planet since the 
last major ice age we may soon enter a decade where the earth returns to a 
"normal" 86400.000 seconds per day or even a bit less. In that case we'll 
switch from positive leap seconds for a while, to no leap seconds for a while, 
to negative leap seconds for a while. We got very close to this during the 
years 2000 - 2007, when we entered the "no leap seconds for a while" stage.

I don't normally cross-post, but I'll cc the leap second list for comments or 
corrections.

/tvb

- Original Message - 
From: "Mark Sims" 
To: 
Sent: Tuesday, July 19, 2016 4:39 PM
Subject: [time-nuts] Leap second to be introduced at midnight UTCDecember 31 
this year


> The GPS satellites are now reporting the pending leapsecond...
> 
> The Z3801A has it messed up...  it says the leap will occur on 30 Sep 2016 
> (73 days).  The Z3801A has two different messages that report the leap day... 
>  both are wrong.  



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

[LEAPSECS] Hawking / PBS TV show about Time

[Tom Van Baak]

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

Re: [LEAPSECS] Kinemetrics/Truetime WWVB model 60-dc?

[Tom Van Baak]

Hi Rob,

> No answer yet from Time-nuts.

There were several replies to your post to time-nuts. The thread is at:

https://www.febo.com/pipermail/time-nuts/2016-April/097575.html

The short answer is that your 60-DC receiver will no longer work. There are 
several ways around this but none of them are simple. Lots of postings on 
time-nuts since 2012 about the effort. With the exception of one or two people, 
everyone else has moved on to NTP for close time, or to GNSS for precise time.

Note that wrist- and desk- and wall-clocks receiving WWVB still work fine. It's 
only the professional receivers, the ones that depended on the 60 kHz carrier, 
that broke. NIST is aware of this; it was a trade-off between full 
compatibility and creating new functionality.

/tvb

- Original Message - 
From: Rob Seaman 
To: Leap Second Discussion List 
Sent: Monday, May 02, 2016 9:16 AM
Subject: [LEAPSECS] Kinemetrics/Truetime WWVB model 60-dc?


Howdy,


Anybody on leapsecs know about this WWVB format change from 2012? I have no 
memory of discussing this from the time, and I’m not finding anything searching 
the message stream. No answer yet from Time-nuts. Is this so well known that my 
question seems naive, or rather, was this change implemented with insufficient 
notice even to the folks on these two lists?


There’s also the section “Enhanced WWVB Broadcast Format Change” here:


http://www.nist.gov/pml/div688/grp40/wwvb.cfm


There’s an excellent history of WWV[B|H]:


http://tf.nist.gov/general/pdf/1969.pdf


Which indicates (p.30) that Datum 9100-series time code generators from the 
1970s were still being used as of 2005 in creating the WWVB signal.


Rob
—


Here’s another: http://www.nist.gov/pml/div688/grp40/upload/Bin-2719.pdf – I 
most definitely would not have been paying any attention to WWVB issues during 
May 2014.




Begin forwarded message:


From: Rob Seaman 

Subject: Kinemetrics/Truetime WWVB model 60-dc?

Date: April 29, 2016 at 4:12:57 PM MST

To: Discussion of precise time and frequency measurement 



Howdy,

We’re in the process of upgrading our telescopes in various ways, including 
deploying spiffy new GNSS clocks. While rummaging around the shelves of old 
equipment, I came across the WWVB time code generators that had been retired 
themselves a dozen years ago or more (in favor of NTP and/or GPS equipment). 
These are Kinemetrics/Truetime model 60-dc. They appears to power up ok to the 
point of displaying the colons and flickering keep-alive LEDs (see p.51 of 
http://www.to-way.com/tf/60dc.pdf). It would be cool to bring them back to 
life, if only to serve as retro wall clocks.

It turns out the old 60 KHz antenna (same manufacturer, model A-60FS) was still 
mounted on the building, but I wasn’t able to get either of the two devices to 
lock when connected to it. The antenna had been repaired at some point, so I 
have no confidence that it's still in working condition after many years out in 
the weather after the case had been opened.

Now I’ve come across this notice from Spectracom:

http://spectracom.com/sites/default/files/document-files/Pending%20Changes%20in%20the%20WWVB%20Radio%20Signal%20Affects%20Precision%20Frequency%20and%20Timing%20Reference.pdf

which suggests that other vendors’ devices might also "no longer operate as 
intended as a result of the WWVB signal change” after July 2012.

If so, bummer!

If not, suggestions for acquiring a functioning antenna?

Many thanks for any information on these or similar devices. I should note that 
another telescope elsewhere on the mountain appears to still be using a Datum 
model 9100 (via Forth software!) nightly (though with WWV, not WWVB?)*  Does 
anybody have a manual for that unit?

Rob Seaman
University of Arizona
—
* there were even some IRIG wall clocks





___
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

[Tom Van Baak]

> Hi Tom,
>
> The values presented in the 2004 Morrison and Stephenson paper are
> already smoothed using a series of cubic splines and a parabola prior
> to -700.  See their table 1 and its discussion.  The authors
> recommended simple interpolation between the listed years, so I did
> that rather than add additional smoothing.

Right. Just use their polynomial then, or go back to their original data.

> To me, the only troubling thing about creating a high-precision
> representation of low-precision data is the implication that the result
> has greater accuracy than its source.  I attempted to address that in
> my conclusion by stating that the choice of extraordinary days in
> ancient times is somewhat arbitrary.

With pUTC you're already throwing away 90% of what UTC stands for. The only 
thing you retain is applying a leap second just before midnight. So instead of 
pages of prose that describe how to do the mapping, with every century or 
decade different, why not just generate a function that converts JD into a 
proleptic leap second count. Since pUTC is fictitious anyway, there's no 
requirement to have the leaps at the end of a month or weirdly spaced on the 
15th or 28th/29th/30th/31st. Instead just generate a leap on the day when it's 
needed, regardless of what day number or month number it is.

I say this because you're generating a subjective table, one based on data from 
a fitted polynomial, which is itself based on measurements of dubious accuracy 
in the first place, measurements that can be revised from time to time 
depending on historical research. The whole thing doesn't pass my smell test.

The other way to think about it, what are you minimizing or maximizing in the 
design of your tables. If someone else comes up with a different table design, 
how do you choose which is better. Is minimum RMS of |DUT1| the goal? Must 
|DUT1| < 0.9 s? How can you be sure? Can you have double leaps instead of 
single leaps twice a month? Must the leaps occur only at the end of a month? 
Why not space them every 365 / N days within a year? Then again, at this level 
you're dealing with JD anyway, so pUTC doesn't itself need to be tied to years, 
or arbitrary power of ten boundaries. Morrison and Stephenson's use of year 
isn't exactly strict.

Think about the code that some poor programmer is going to have to write as 
they read your PDF. Instead of an if-else-if sequence that goes on for pages, 
is there a simpler way to generate pUTC? I mean, no human is going to read your 
PDF and manually go through the guidelines you present. So maybe think of the 
code first instead of the prose.

It looks to me like you have a subjective solution looking for a poster child 
problem. I would feel much better if you or anyone else on the list could start 
with a couple of real examples of a problem, and then consider what algorithmic 
solutions solve the problem.

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

Re: [LEAPSECS] Leap Seconds schedule prior to 1972

[Tom Van Baak]

> I neglected to mention the URL for my revised paper.  It is
>
> https://www.systemeyescomputerstore.com/proleptic_UTC.pdf
>
>John Sauter (john_sau...@systemeyescomputerstore.com)

Hi John,

Given that your pUTC is pure fiction, though possibly useful fiction, did you 
consider a simple polynomial fit of the Morrison and Stephenson data, instead 
of those hideous, every-one-is-different, per-century and per-decade pseudo 
leap second tables of yours?

I'll try to put my finger on it, but there's something troubling about taking a 
table that clearly contains numbers of very low precision and then creating a 
table with algorithms and dates of high resolution.

I have more comments too, but let's start with this one.

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

[LEAPSECS] World map of the difference between solar and clock time

[Tom Van Baak]

Very nice solar vs. local time map:
http://blog.poormansmath.net/images/SolarTimeVsStandardTimeV2.png

Article:
http://blog.poormansmath.net/the-time-it-takes-to-change-the-time

Comments:
https://news.ycombinator.com/item?id=10319681

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

Re: [LEAPSECS] countdown to WRC-15

[Tom Van Baak]

Hi Harlan,

Look back in the archives for LSEM (Leap Second Every Month) discussions. The 
idea was to have a leap second at the end of every month, always. It would 
force all precision timing systems to correctly deal with leap seconds, 
positive as well as negative. DUT1 would remain  0.7 s. By sheer annoyance it 
would force the automation of the leap second notification infrastructure. A 
past record or future scheduling of leap seconds could be encoded into as 
little as 12-bits per year.

LSEM would elevate leap seconds from unpredictable and rare to certain and 
common. Errors in software would be found within a month or two instead of many 
years. It would get rid of the awkward June/December convention, and track 
impending changes in Earth rotation 6x better. The next generation of school 
children would all know about leap seconds just like all children already know 
about leap years. It is compatible with WWVB and GPS and NTP and smearing 
algorithms.

It would also solve a serious problem with UTC clocks today: not knowing if 
there is a leap second vs. knowing there is no leap second. The two states are 
currently indistinguishable but LSEM would allow you to know the difference. It 
replaces two unknowns (when is the next leap second and what sign will it be) 
with one unknown (what sign will it be this month).

Of course the cost of LSEM would be prohibitive, but it's still an elegant idea 
on paper.

/tvb

- Original Message - 
From: Harlan Stenn st...@ntp.org
To: Leap Second Discussion List leapsecs@leapsecond.com
Sent: Saturday, August 29, 2015 12:49 PM
Subject: Re: [LEAPSECS] countdown to WRC-15


 I've not been able to follow these discussions.  I look forward to the
 time when there's less pressure on my schedule.
 
 Has anybody put forth the following position:
 
 - The various current popular timescales are of significant value.
 
 - (a variety of points covering the backstory, foundation, and
  pros/cons of these timescales.)
 
 - If something doesn't happen often enough it's difficult for people
  who have to deal with these events to easily accomodate them.  As a
  case in point, I offer full/proper handling of leap years in
  calendars.  I submit this situation was not properly handled until 1)
  the internet made it easy to copy/paste code, and 2) Y2K got everybody
  looking at their date code.
 
 - So I propose that every N months' time, where N is 1-6, we schedule
  either an addition or a deletion of a leap second.  In doing so, we
  make it compelling for leap seconds to be properly handled, and I
  submit that the problem of handling leap seconds will be resolved
  satisfactorily within 1-2 years' time.
 
 Are there significant additional costs to implementing this approach
 when compared to the costs of continuing to only address leap seconds as
 needed?
 
 I'm hesitant to have asked that, as it's akin to asking what the costs
 are to changing UTC so it doesn't have leap seconds.  This is all about
 how to lie with statistics, except that the scope is much smaller.
 
 I'll point out that a side issue is that there are HUGE number of
 ancient versions of NTP out there and too many folks are being slow to
 update.  Dealing with leap second additions and deletions will be yet
 another incentive to upgrade this software. 
 
 -- 
 Harlan Stenn st...@ntp.org
 http://networktimefoundation.org  - be a member!
 ___
 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] Why the Greenwich meridian moved

[Tom Van Baak]

For those of you that have been at this a while, the exact location of zero 
longitude is very interesting. Not just for astronomy, but also in the history 
of precise timekeeping. An alert reader pointed me to a great article, just 
published (and free PDF).

Why the Greenwich meridian moved
http://link.springer.com/article/10.1007/s00190-015-0844-y
http://link.springer.com/content/pdf/10.1007%2Fs00190-015-0844-y.pdf

See also: http://leapsecond.com/pages/meridian/ for my recent visit.

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

[LEAPSECS] GLONASS leap second

[Tom Van Baak]

Richard, or Martin, or anyone,

What's the latest on how GLONASS handles leap seconds? I remember years ago 
receivers (or the SV itself) reset their timescale across the leap event -- 
because they use UTC(SU)+3h (Moscow local time) as their system time and not a 
leap-less, timezone-free timescale like GPS system time.

Multi-GNSS receivers might be able ride through this with some heuristic so the 
question is more what really happens underneath, or to GLONASS-only receivers 
these days?

Thanks,
/tvb


(2013) GLONASS TIME AND UTC(SU)
http://spacejournal.ohio.edu/issue9/pdf/UsingGLONASS.pdf

(2013) GLONASS and Coordinated Universal Time
https://itunews.itu.int/En/4275-GLONASS-and-Coordinated-Universal-Time.note.aspx

(2008) GLONASS ICD
https://www.unavco.org/help/glossary/docs/ICD_GLONASS_5.1_(2008)_en.pdf

(2005) Using GLONASS in Combined GNSS Receivers: Current Status 
http://www.unoosa.org/pdf/icg/2013/icg-8/wgD/D4a.pdf

(2001) The leap second: its history and possible future
https://www.cl.cam.ac.uk/~mgk25/time/metrologia-leapsecond.pdf

(1999) GPS and Leap Seconds: Time to Change?
http://www2.unb.ca/gge/Resources/gpsworld.november99.pdf

(1990) CURRENT GPS/GLONASS TIME REFERENCES AND UTC 
http://tycho.usno.navy.mil/ptti/1990papers/Vol%2022_06.pdf

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

Re: [LEAPSECS] leap second festivities?

[Tom Van Baak]

 What are people’s plans for the day?

Some ideas: http://leapsecond.com/notes/leap-watch.htm

For the previous leap second in June 2012 I happened to be on a family vacation 
on a remote beach in the southern hemisphere. I built a sundial out of 
driftwood and traced the shadow (counter-clockwise).

/tvb

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

Re: [LEAPSECS] leap second festivities?

[Tom Van Baak]

Some clocks are right twice a day. This one once every few years:

http://leapsecond.com/images/CD47-235960.jpg

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

[LEAPSECS] a new type of negative leap second

[Tom Van Baak]

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

Re: [LEAPSECS] Google, Amazon, now Microsoft

[Tom Van Baak]

 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.

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

Re: [LEAPSECS] Google, Amazon, now Microsoft

[Tom Van Baak]

 On 31 May 2015, at 03:28, Rob Seaman sea...@noao.edu wrote:

 DST changes at 2am in the US and 1am in the EU.
 
 That is 01:00 UTC which is 02:00 standard / 03:00 summer time for most of
 the EU.
 
 Tony.

Tony, that's my understanding too, that all DST changes always occur at 2am 
local time, both times a year.

Rob, where did you see the 1am documented?

/tvb

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

Re: [LEAPSECS] Google, Amazon, now Microsoft

[Tom Van Baak]

Rob (or Steve),

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).

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.

/tvb


- Original Message - 
From: Rob Seaman sea...@noao.edu
To: Tom Van Baak t...@leapsecond.com
Cc: Leap Second Discussion List leapsecs@leapsecond.com
Sent: Monday, June 01, 2015 11:27 AM
Subject: Re: [LEAPSECS] Google, Amazon, now Microsoft


Hi Tom,

 Tony, that's my understanding too, that all DST changes always occur at 2am 
 local time, both times a year.
 
 Rob, where did you see the 1am documented?

Got me. Rummaging through zoneinfo, however, many different pivot hours have 
been used. The point was just that there is nothing special about midnight 
local time.

Rob

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

Re: [LEAPSECS] Google, Amazon, now Microsoft

[Tom Van Baak]

 You'll need a faster car. Or a plane. Maybe we could get the guys on the 
 space station to try it?

Hi Brooks,

On the equator, timezones fly by about 1000 mph (earth diameter is ~25000 
miles, day is ~24 hours). So that excludes cars and commercial planes.

Even up here at 45 degrees latitude, timezones fly by about 700 mph 
(approximately the speed of sound). Still too fast for cars and private jets.

Your best bet is to contact someone in the arctic or antarctic and have them 
experience all 24 Azure leap seconds during the day of June 30, 2015. You 
perhaps have seen cool timezone photos from Amundsen-Scott.

I say this only partly in jest. It would make a fine blog entry for someone to 
pull this off. Not only would it be another dramatic refutation of ancient flat 
earth theories but it would also nicely demonstrate the increasing disparity 
between the needs of medieval astronomy, interstate railroads, and modern 
computing and timekeeping.

The guys at Google, Amazon, and Microsoft are only trying to solve real 
problems and best serve their customers. They are not stupid. The official ITU 
or the glossy DHS guidelines for leap seconds don't help them. So when they 
decide to smear or jump time in 2015 instead of implementing a 1960's solution 
you need to sit up and listen.

/tvb

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

Re: [LEAPSECS] Google, Amazon, now Microsoft

[Tom Van Baak]

 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. 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. This recent fix 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. Yes, I know it's against UTC rules.

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. 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

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

[LEAPSECS] Look Before You Leap – The Coming Leap Second and AWS | Hacker News

[Tom Van Baak]

https://aws.amazon.com/blogs/aws/look-before-you-leap-the-coming-leap-second-and-aws/

https://news.ycombinator.com/item?id=9567761

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

Re: [LEAPSECS] GPS week-number data field size (was W1K GPS rollover for some time servers)

[Tom Van Baak]

Hi Peter,

GPS, as well as multiple other national GNSS systems, continues to evolve. 
There are new frequencies and new data formats. I suspect new receivers will be 
backwards compatible with old signals and formats for a long time. Sorry, I 
don't have carefully prepared set of links for you, but here's a couple:

http://www.gps.gov/systems/gps/modernization/civilsignals/
http://gpsworld.com/air-force-directs-early-civil-navigation-cnav-message-populated-l2c-and-l5-signals/
http://www.digitaltrends.com/mobile/gps-iii-explained-everything-you-need-to-know-about-the-next-generation-of-gps/
http://en.wikipedia.org/wiki/GPS_signals#Modernization_and_additional_GPS_signals

In that last link, note The GPS week number is now represented as 13 bits, or 
8192 weeks, and only repeats every 157.0 years, meaning the next return to zero 
won't occur until the year 2137. This is longer compared to the L1 NAV 
message's use of a 10-bit week number, which returns to zero every 19.6 years.

You even get DUT1 in:
http://www.navcen.uscg.gov/pdf/gps/IS-GPS-800.pdf
http://www.gps.gov/technical/icwg/
http://www.navipedia.net/index.php/GPS_Signal_Plan

There was once a time when your sounds fraught with problems would be my 
response too! But we survived going from 36-bit computers to 16 bits. And from 
16 to 32, and 32 to 64. I once tapped ethernet coax cables with a drill and now 
we have fraught with problems RJ45 connectors. There there's USB 1 and 2 and 3. 
And IPv4 and IPv6. Cars evolved from 12 VDC cigarette lighter power sockets to 
fraught with problems 5 VDC USB sockets. My next car probably won't even have a 
cassette player!

So by now I'm now more confident that changes can safely occur in technology. 
The slower and more carefully planned the better. But adapting to new 
requirements, to new possibilities, to new performance is ok. This is one 
reason why I sympathize with those who want to abandon leap seconds. When leap 
seconds were proposed in the 60's, AC plugs were all 2-prong, radio chassis 
were hot, DOS didn't exist, 110 baud was standard, electronic voltages were 6.3 
VAC (filament) and ~250 VDC (plate B+), there were no quartz wrist watches, or 
airbags. Evolution is ok. It might even be natural.

/tvb

- Original Message - 
From: Peter Vince 
To: Tom Van Baak ; Leap Second Discussion List 
Sent: Tuesday, May 05, 2015 1:20 AM
Subject: GPS week-number data field size (was W1K GPS rollover for some time 
servers)


Hi Tom,



On 5 May 2015 at 00:40, Tom Van Baak t...@leapsecond.com wrote:

As you know the GPS folks enlarged the 10-bit week number in the next signal 
spec so receiver manufacturers have less rope to hang themselves. 



Actually I wasn't aware of that, but am curious how it can be implemented in a 
working system.  All the old software will just be expecting a 10-bit number - 
will every GPS receiver need new software as of a certain date?  Sounds fraught 
with problems!


Regards,


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

Re: [LEAPSECS] Civil timekeeping before 1 January 1972

[Tom Van Baak]

 The tabulations of the times of emission of radio broadcasts of UTC
 were given in units of, and with an accuracy of 0.0001 s; i.e., 100
 microseconds.
 
 The tabulations of the intercomparisons between the time scales in
 those laboratories are given with decimals to 0.1 microsecond, or 100
 nanoseconds.
 
 I don't believe 3 ns is significant for any time stamp from that
 era.

Steve and Paul,

To further add perspective to 1960's timescales, read these wonderful papers:

Correlating Time from Europe to Asia with Flying Clocks
http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1965-04.pdf

World-Wide Time Synchronization, 1966
http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1966-08.pdf

'Flying Clock' Comparisons Extended to East Europe, Africa and Australia
http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1967-12.pdf

The articles should give you a better feel for what timekeeping, clocks, and 
timescales are. Does your C# code incorporate the notion of error bars? If your 
users are scientific, perhaps they need to know how uncertain timescale 
conversions are.

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

Re: [LEAPSECS] W1K GPS rollover for some time servers

[Tom Van Baak]

 As seen at
 http://lists.ntp.org/pipermail/hackers/2015-May/006866.html
 and also as experienced at Keck Observatory last night, some models
 of GPS time servers just did their firmware's W1K rollover, so those
 are saying the date is 1995-09-17.
 
 But the leap second is, inappropriately, getting the blame!

Steve,

Oh, this will make your day! Look what was just announced (and read the field 
service bulletin in the PDF attachment):

https://www.febo.com/pipermail/time-nuts/2015-May/091799.html

So, yes, we can sort of blame it on leap seconds. Or, actually, the lack of 
leap seconds. All this because the earth has been speeding back up the past 
decade.

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

Re: [LEAPSECS] W1K GPS rollover for some time servers

[Tom Van Baak]

 As seen at
 http://lists.ntp.org/pipermail/hackers/2015-May/006866.html
 and also as experienced at Keck Observatory last night, some models
 of GPS time servers just did their firmware's W1K rollover, so those
 are saying the date is 1995-09-17.
 
 But the leap second is, inappropriately, getting the blame!

Steve,

No need to take it personally. At some level it doesn't matter if it's leap 
seconds, or the GPS spec, or one GPS manufacturer, or one particular GPS 
receiver model, or one OS, or one line of code that doesn't handle rollover 
correctly. To the person who wants and expects time to work right, it's all the 
same. And any of us who work with precise time are part of the problem and 
share the blame.

What you can do is represent the astronomical community and do what you can in 
your professional career to promote clean, robust, and redundant timekeeping. 
That can either be passive education or active steering the future away from 
sextants, s/w radio, and other outdated methods of astronomical timekeeping. 
That doesn't make problems vanish right away, it helps reduce risk in the 
future.

As you know the GPS folks enlarged the 10-bit week number in the next signal 
spec so receiver manufacturers have less rope to hang themselves. One step at a 
time, but at least it's a step.

The shame in today's example rests on makers of TymServe 2100, who either 
didn't test their firmware, or who knowingly allowed a product to have this 
bug. And worse yet, are now refusing to support it, because it's out of 
warranty. Hopefully a two-line fix to NTP can be used to get around the bug. 
OTOH, I can't believe the Keck guys are reliant on a single GPS receiver for 
their time? May I bring them another clock or two for them to use?

/tvb

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

Re: [LEAPSECS] LOD and gravity connected ?

[Tom Van Baak]

Thanks for the link. I see the PDF is free this time.

/tvb

- Original Message - 
From: Poul-Henning Kamp p...@phk.freebsd.dk
To: Leap Second Discussion List leapsecs@leapsecond.com
Sent: Wednesday, April 29, 2015 2:32 AM
Subject: [LEAPSECS] LOD and gravity connected ?


   http://iopscience.iop.org/0295-5075/110/1/10002/article
 
 -- 
 Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
 p...@freebsd.org | TCP/IP since RFC 956
 FreeBSD committer   | BSD since 4.3-tahoe
 Never attribute to malice what can adequately be explained by incompetence.
 ___
 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] Question about UT1 and the IERS Reference Meridian

[Tom Van Baak]

BTW, this excellent question came to time-nuts yesterday; does anyone here have 
a definitive answer for Mike?

Thanks,
/tvb

- Original Message - 
From: mflaws...@cox.net
To: time-n...@febo.com
Sent: Tuesday, April 28, 2015 8:06 PM
Subject: [time-nuts] Question about UT1 and the IERS Reference Meridian

 Okay, I've tried to research this for a few days, and seem to be running 
 into conflicting data.
 
 Some articles say that UT1 is based on the IERS Reference Meridian (IRM). 
 Other articles say that UT1 is based on mean solar time at the Prime 
 Meridian (Greenwich).  It can't be both!  Which one is it?   In other words, 
 which meridian would I need to stand on to indicate Solar Noon as 
 12:00:00.000 (UT1) on a day of the year where the equation of time is 0 
 seconds offset?
 
 From what I can reckon, a 200-400 millisecond difference exists between the 
 two longitudes, which are separated by about ~102 meters at Greenwich.  So, 
 if UT1 (and hence UTC) is based on the IRM and not the Prime Meridian, then 
 at some point did clocks have to be adjusted ~200 milliseconds away from 
 the Prime Meridian when the IRM was defined?  Or was it sloppy and they 
 treated the two as one and the same?
 
 Anyone know? 

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

Re: [LEAPSECS] UTC fails

[Tom Van Baak]

Steve,

 And UTC has failed miserably.  POSIX says UTC has no leaps.
 Google says UTC has occasional days with stretches of seconds which
 are of varying lengths.  De facto, there is no single UTC time scale.

Right! And many more examples of UTC fails -- the RTC of any unix computer. Any 
windows computer. Arduino and the microcontroller world. GPS receivers 
displaying 59 twice or 00 twice. IRIG. FAT (memory cards). Excel. eBay. Analog 
clocks.

It's getting increasingly awkward decade after decade to have all these holes 
in the practical implementation of UTC. Remember the paper that started all of 
this had time to change in the title:
http://gauss.gge.unb.ca/papers.pdf/gpsworld.november99.pdf

Remember also that in the 60's when leap seconds were conceived there were no 
personal computers, no quartz wrist watches, no internet, sailors used sextants 
or LORAN, WWV ticked on short-wave, teletypes were 110 baud, NASA used nixie 
tubes (no LED's), phones were black and rotary, you could dial in town with 4 
digits, TV's had 3 channels, computers were the size of rooms and turned off at 
night, etc. Almost nobody knew about or was affected by leap seconds.

It was a reasonable technical solution for the era. I think those that want to 
get rid of leap seconds have a point; it is too awkward a universal solution 
for the 21st century.

 But the bottom line for engineers who are implementing operational
 systems that depend on timing is much simpler.
 
 If you want to engage with a 15 year long international flame war
 where people cannot agree on elapsed time to within several seconds,
 then go ahead, choose the internationally-recommended UTC.
 
 But if you want to get something working that does not get bothered by
 differences of several nanoseconds, then ignore the international
 recommendations and choose GPS time, Galileo, BeiDou, the Indian
 satellite system time, or some PTP-based system via a device which
 claims to be using one of those to supply TAI.

Good point. I agree. But its sad. And would have been unnecessary. This 
proliferation of timescales, even back in the late 90's, is the main reason (so 
I was told) that USNO proposed that leap seconds be re-considered. Dennis can 
provide more info if he's still on the list.

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

Re: [LEAPSECS] Civil timekeeping before 1 January 1972

[Tom Van Baak]

Brooks wrote:
 Many timekeeping systems seem to be designed for only indicating now
 counting forward, including NTP, POSIX, and PTP, taking short-cuts to
 avoid supplying full Leap Second and local-time metadata.

Warner wrote:
 A clock doesn’t need to know its past. But a time scale is more than just how
 many seconds the current minute will have. It has a history and to compute
 elapsed time in that time scale, you need to know its history.

Ok, thanks. So there's a terminology issue among Brooks' timekeeping system, 
Tom's clock, and Warner's timescale.

I didn't think that NTP or POSIX or PTP is what we'd call a timescale. NTP is a 
UTC synchronization algorithm. UT0 is a measurement. UT1 is a timescale. TAI is 
a timescale. UTC is a timescale. There are clock ensemble algorithms. There are 
time transfer methods. There are time encoding conventions. There are time 
API's in languages, libraries, or operating systems.

WWVB is not a timescale. It is a time (and frequency) transfer service for 
UTC(NIST). GPS is not a timescale. It is a navigation positioning (and time 
transfer) service based on UTC(USNO).

I'm not trying to pick a fight here. Just trying to seek clarification. I guess 
I still don't understand what Brooks is trying to sell, or why full 
historical phase or frequency records are any part of timekeeping, or time 
transfer.

Put it another way -- Brooks, what information could WWVB or GPS (GNSS) further 
provide to satisfy your clientele? Must you rely on hardcopy historical journal 
articles, on-air data, or web-based tables to satisfy your timekeeping 
requirement?

I do a lot of timekeeping here, old and new. What time_t looked like before 
1972 is not a problem. Yes, civil timekeeping (before or after 1972) is an 
interest to me. But all the older stuff arrives in the form of faded paper, or 
JPG photos, or TXT files. I would never think of trying to encode that into 
some 32 or 64 bit binary format.

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

Re: [LEAPSECS] Civil timekeeping before 1 January 1972

[Tom Van Baak]

 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.

You've got to be kidding. Who on earth decided on only 12 hours notice? And 8 
weeks is wrong too, for a different reason.

You can have 8 weeks of notice (or 6 months or 100 weeks) as long as you are 
given the actual future date of the leap second, as is done with GPS. You can 
get away with single warning bits too, as long as they apply to current month 
only, as is done with WWVB. Both of these are models on how to send out leap 
second notifications correctly. But allowing 8 weeks without a way to know 
which month it will occur in is wrong. For bit-only leap second warnings 4 
weeks is the limit.

/tvb

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

[LEAPSECS] BeiDou Numbering Presents Leap-Second Issue

[Tom Van Baak]

http://gpsworld.com/beidou-numbering-presents-leap-second-issue/___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs

Re: [LEAPSECS] My FOSDEM slides

[Tom Van Baak]

 GPS can deal with it, even IEEE 1344 and C37.118 time codes can, but I'm 
 not sure if WWVB can. Anyway, I know the German DCF-77 transmitter has 
 no flag defined to announce a negative leap second, so there would be 
 major problems if one had to be inserted.

Both WWVB and DCF-77 have a single leap second warning bit. With WWVB you look 
at the sign of DUT1 to know if the leap is insert or delete. So WWVB is fine.

DCF-77 has no DUT1 or leap gender bit so, yes, there will be trouble. I'm sure 
PTB will figure something out if it ever comes to that.

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

Re: [LEAPSECS] final report of the UK leap seconds dialog

[Tom Van Baak]

Hi Stephen,

You're not looking in the wrong places. In fact there is no need to look at all.

Local time is conventionally (legally) an offset from UTC and so if/when UTC 
steps so does local time. There is no need for a local decision or 
international standards in this regard. Everyone living in a timezone that is 
expressed as an offset from UTC gets leap seconds for free, and they all occur 
at the same instant around the globe.

This next leap second will appear at 05:44:60 NPT in Kathmandu and 08:59:60 JST 
in Tokyo, local time, 1 July. Note neither nation observes DST. In Seattle, 
however, a June leap second occurs just before 5 PM PDT (UTC-7) and just before 
4 PM PST (UTC-8) if December.

/tvb

- Original Message - 
From: Stephen Scott 
To: leapsecs@leapsecond.com 
Sent: Thursday, February 05, 2015 1:37 PM
Subject: Re: [LEAPSECS] final report of the UK leap seconds dialog


Hello Kevin.

The information specifying that for Japan the next Leap Second will be applied 
Wednesday, July 1, at 9:00. is interesting in that this is the first official 
policy on when the Leap second shall be applied to a local timescale. Maybe I 
have been looking in teh wrong places. 
This is a local decision for a local time.
 I am not aware of any international standards that touch the subject.
I would be interested in learning about other jurisdictions that may have 
published a policy.


Stephen Scott
  
On 2015-02-05 09:35, Kevin Birth wrote:

Wednesday, July 1, at 9:00.

___
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] final report of the UK leap seconds dialog

[Tom Van Baak]

 Many aspects of local time or civil time are left to common 
 practice which is not good enough to expect uniform inter-operable 
 implementations.

Brooks, can you give some examples?

 We here concentrate on discussions of UTC and Leap 
 Seconds, which is foundational, yet obviously local time is required 
 and there's nearly a complete lack of standards that govern it.

I'm surprised to hear this. A complete lack of standards, really? What, in 
your opinion, would a complete set of standards look like?

 Fixing
 Leap Seconds, either by more clearly defining it so implementations can 
 get it right (my very strong preference)

What do you mean by get it right? Is there an error in the specification or 
is there a flaw in the implementation? Is there only one true implementation? 
When an implementation does not get it right, is the root cause an error in 
the definition, or in the clarity of the definition, or something else?

 or ceasing Leap Seconds (which 
 some hope will mitigate the problems but I believe will make it worse) 
 doesn't address the elephant in the room - local time.

How would ceasing leap seconds affect your world of video time codes?

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