A Satellite Navigation and Global Positioing Systems forum. Sat Nav Banter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » Sat Nav Banter forum » GPS and Sat Nav Newsgroups » sci.geo.satellite-nav (Global Satellite Navigation)
Site Map Home Authors List Search Today's Posts Mark Forums Read Web Partners

sci.geo.satellite-nav (Global Satellite Navigation) (sci.geo.satellite-nav) Discussion of global navigation satellite systems (GNSS). Topics include the technical aspects of GNSS operation, user experiences in the use of GNSS, information regarding GNSS products and discussion of GNSS policy (such as GPS selective availability).

As June 30 Nears, Leap Second Looms



 
 
Thread Tools Display Modes
  #1  
Old June 23rd 15, 05:39 PM posted to sci.geo.satellite-nav
Sam Wormley[_2_]
external usenet poster
 
Posts: 775
Default As June 30 Nears, Leap Second Looms

As June 30 Nears, Leap Second Looms
http://gpsworld.com/as-june-30-nears-leap-second-looms/


The world’s clocks will be adjusted by one second one week from today
on June 30, when a leap second will be inserted into Coordinated
Universal Time (UTC), the standard international time scale.

The financial market is preparing for potential disruptions. The
adjustment could present technical difficulties for traders and
exchanges, as some computers might not be programmed to account for
the adjustment.

In theory, all UTC clocks should insert a second labeled 23h 59m 60s
(the leap second) following one labeled 23h 59m 59s UTC. This is
equivalent to having all of the clocks in the world stop for one
second at that time, as explained in May’s Expert Advice column.

Several legacy GPS receivers immediately and incorrectly applied a
leap second correction as early as January, or showed incorrect
leap-second-pending data when queried due to an incorrect
interpretation of the GPS specification by the firmware programmers
of those GPS receivers, according to Jackson Labs Technologies.

To help affected industries prepare, the DHS National Coordinating
Center for Communications issued guidance with a paper titled “Best
Practices for Leap Second Event Occurring on 30 June 2015.”


  #2  
Old June 23rd 15, 06:19 PM posted to sci.geo.satellite-nav
Alan Browne
external usenet poster
 
Posts: 1,339
Default As June 30 Nears, Leap Second Looms

On 2015-06-23 12:39, Sam Wormley wrote:
As June 30 Nears, Leap Second Looms
http://gpsworld.com/as-june-30-nears-leap-second-looms/


The world’s clocks will be adjusted by one second one week from today
on June 30, when a leap second will be inserted into Coordinated
Universal Time (UTC), the standard international time scale.

The financial market is preparing for potential disruptions. The
adjustment could present technical difficulties for traders and
exchanges, as some computers might not be programmed to account for
the adjustment.

In theory, all UTC clocks should insert a second labeled 23h 59m 60s
(the leap second) following one labeled 23h 59m 59s UTC. This is
equivalent to having all of the clocks in the world stop for one
second at that time, as explained in May’s Expert Advice column.

Several legacy GPS receivers immediately and incorrectly applied a
leap second correction as early as January, or showed incorrect
leap-second-pending data when queried due to an incorrect
interpretation of the GPS specification by the firmware programmers
of those GPS receivers, according to Jackson Labs Technologies.

To help affected industries prepare, the DHS National Coordinating
Center for Communications issued guidance with a paper titled “Best
Practices for Leap Second Event Occurring on 30 June 2015.”



It astounds me that there still may be systems out there that are
critically sensitive to time-of-day and yet not compatible with leap
second insertion.
  #3  
Old June 24th 15, 08:13 AM posted to sci.geo.satellite-nav
Terje Mathisen[_3_]
external usenet poster
 
Posts: 25
Default As June 30 Nears, Leap Second Looms

Alan Browne wrote:
On 2015-06-23 12:39, Sam Wormley wrote:
As June 30 Nears, Leap Second Looms
http://gpsworld.com/as-june-30-nears-leap-second-looms/

[snip]
To help affected industries prepare, the DHS National Coordinating
Center for Communications issued guidance with a paper titled �Best
Practices for Leap Second Event Occurring on 30 June 2015.�



It astounds me that there still may be systems out there that are
critically sensitive to time-of-day and yet not compatible with leap
second insertion.


It is indeed astounding, but you should probably blame Posix:

Posix is required for many (most?) US government contracts and it
specifies a clock scheme which is intrinsically incompatible with
reality, i.e. leap seconds:

a) Posix time follows UTC

b) All posix days have exactly 86400 seconds

There are other interesting issues as well, like the realtime scheduling
API which can only accept absolute times, i.e. if you want to wait 0.5s
you have to retrieve the current time, add 0.5 to it and then pass in
the results as the time to wait until.

The problem is of course that this breaks down during leap events, and
there is no way for the OS to figure out exactly what you meant: Is the
new target time including or excluding the leap second which will occur
shortly?

Terje

--
- Terje.Mathisen at tmsw.no
"almost all programming can be viewed as an exercise in caching"
  #4  
Old June 24th 15, 03:22 PM posted to sci.geo.satellite-nav
Alan Browne
external usenet poster
 
Posts: 1,339
Default As June 30 Nears, Leap Second Looms

On 2015-06-24 03:13, Terje Mathisen wrote:
Alan Browne wrote:
On 2015-06-23 12:39, Sam Wormley wrote:
As June 30 Nears, Leap Second Looms
http://gpsworld.com/as-june-30-nears-leap-second-looms/

[snip]
To help affected industries prepare, the DHS National Coordinating
Center for Communications issued guidance with a paper titled �Best
Practices for Leap Second Event Occurring on 30 June 2015.�


It astounds me that there still may be systems out there that are
critically sensitive to time-of-day and yet not compatible with leap
second insertion.


It is indeed astounding, but you should probably blame Posix:

Posix is required for many (most?) US government contracts and it
specifies a clock scheme which is intrinsically incompatible with
reality, i.e. leap seconds:

a) Posix time follows UTC

b) All posix days have exactly 86400 seconds

There are other interesting issues as well, like the realtime scheduling
API which can only accept absolute times, i.e. if you want to wait 0.5s
you have to retrieve the current time, add 0.5 to it and then pass in
the results as the time to wait until.


In freepascal I simply put in:

sleep (500); //

and the process is suspended for 500 ms (minimum - may take longer).
How free pascal actually achieves that is not mentioned in the manual.

But I can see how that could be an issue during a leap second if there
was some critical task around/during that time.

The problem is of course that this breaks down during leap events, and
there is no way for the OS to figure out exactly what you meant: Is the
new target time including or excluding the leap second which will occur
shortly?


I just read the Wikipedia article on Unix time. Indeed doesn't allow
any simple fix to the issue unless Posix redefines time keeping.

OTOH, the UTC time displayed on my computer is correct v official time
sites - is that NTP taking care of it?
  #5  
Old June 25th 15, 06:44 AM posted to sci.geo.satellite-nav
Terje Mathisen[_3_]
external usenet poster
 
Posts: 25
Default As June 30 Nears, Leap Second Looms

Alan Browne wrote:
On 2015-06-24 03:13, Terje Mathisen wrote:
The problem is of course that this breaks down during leap events, and
there is no way for the OS to figure out exactly what you meant: Is the
new target time including or excluding the leap second which will occur
shortly?


I just read the Wikipedia article on Unix time. Indeed doesn't allow
any simple fix to the issue unless Posix redefines time keeping.

OTOH, the UTC time displayed on my computer is correct v official time
sites - is that NTP taking care of it?


Pretty much all computers on or or off the internet is using some form
of NTP to tract UTC time, the problem is just in what to do during those
leap events:

The correct method is to insert that extra second in 5 days time,
calling it 2015-06-30 23:59:60, before switching the date to July 1st.

This is _not_ doable if you also measure time as a monotonic number of
seconds, with every day having exactly 86400 of them.

The main problem is that we've been lazy enough to use seconds for what
should have been calendar calculations.

Possibly the best fix is the "Right" timezone which allows local time
zones (including the UTC zone) to have an arbitrary number of seconds
offset from a strictly monotonic clock (TAI) which has no leap seconds.

The core problem is still that you have to schedule future events as
calendar day + time zone + offset into the day, _not_ as a Posix time_t
seconds value!

Terje

--
- Terje.Mathisen at tmsw.no
"almost all programming can be viewed as an exercise in caching"
  #6  
Old June 25th 15, 04:56 PM posted to sci.geo.satellite-nav
Alan Browne
external usenet poster
 
Posts: 1,339
Default As June 30 Nears, Leap Second Looms

On 2015-06-25 01:44, Terje Mathisen wrote:
Alan Browne wrote:
On 2015-06-24 03:13, Terje Mathisen wrote:
The problem is of course that this breaks down during leap events, and
there is no way for the OS to figure out exactly what you meant: Is the
new target time including or excluding the leap second which will occur
shortly?


I just read the Wikipedia article on Unix time. Indeed doesn't allow
any simple fix to the issue unless Posix redefines time keeping.

OTOH, the UTC time displayed on my computer is correct v official time
sites - is that NTP taking care of it?


Pretty much all computers on or or off the internet is using some form
of NTP to tract UTC time, the problem is just in what to do during those
leap events:

The correct method is to insert that extra second in 5 days time,
calling it 2015-06-30 23:59:60, before switching the date to July 1st.

This is _not_ doable if you also measure time as a monotonic number of
seconds, with every day having exactly 86400 of them.

The main problem is that we've been lazy enough to use seconds for what
should have been calendar calculations.


That depends. If I need a task to run in 6 seconds from now, then I
don't care about the absolute value of "now" nor at the time the task
starts. Start_t := now + 6 is pretty efficient code too. Once the LS
is inserted, the task will be 1s late of course.

There are states (TIME_OK, TIME_INS, TIME_DEL) that can be monitored in
refclock_local.c (part of the ntp source package) for LS insertion, but
that would mess up the code a little and be inefficient for 18 months or
so between LSI's. Not sure how one links to the running ntpd signals
however.

Possibly the best fix is the "Right" timezone which allows local time
zones (including the UTC zone) to have an arbitrary number of seconds


offset from a strictly monotonic clock (TAI) which has no leap seconds.

The core problem is still that you have to schedule future events as
calendar day + time zone + offset into the day, _not_ as a Posix time_t
seconds value!


That would still fail the above condition w/o foreknowledge of the leap
second within the delay period.

  #7  
Old July 7th 15, 09:35 PM posted to sci.geo.satellite-nav
J. J. Lodder
external usenet poster
 
Posts: 572
Default As June 30 Nears, Leap Second Looms

Sam Wormley wrote:

As June 30 Nears, Leap Second Looms
http://gpsworld.com/as-june-30-nears-leap-second-looms/


The world's clocks will be adjusted by one second one week from today
on June 30, when a leap second will be inserted into Coordinated
Universal Time (UTC), the standard international time scale.

The financial market is preparing for potential disruptions. The
adjustment could present technical difficulties for traders and
exchanges, as some computers might not be programmed to account for
the adjustment.

In theory, all UTC clocks should insert a second labeled 23h 59m 60s
(the leap second) following one labeled 23h 59m 59s UTC. This is
equivalent to having all of the clocks in the world stop for one
second at that time, as explained in May's Expert Advice column.

Several legacy GPS receivers immediately and incorrectly applied a
leap second correction as early as January, or showed incorrect
leap-second-pending data when queried due to an incorrect
interpretation of the GPS specification by the firmware programmers
of those GPS receivers, according to Jackson Labs Technologies.

To help affected industries prepare, the DHS National Coordinating
Center for Communications issued guidance with a paper titled "Best
Practices for Leap Second Event Occurring on 30 June 2015."


And, has anyone kept track of all the looming leap second catastrophes
averted by heroic effort, at last second even?

Jan
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 01:54 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.SEO by vBSEO 2.4.0
Copyright ©2004-2018 Sat Nav Banter.
The comments are property of their posters.