Hello,

As I am in the process of creation of my own Nixie clocks. And it
probably good time frame to clarify one thing about leap seconds. In my
project I am using GPS module as an option to have current UTC time and
also to have 1PPS signal to do auto-adjustment for external RTC module.
The question is how usually GPS modules handle leap seconds ? Is it
satelates who send UTC time to GPS module or GPS module has firmware
with leap second information hard-coded ?
The same question is for UNIX epoch time. How computers knows if it is
necessary to add leap seconds ? Lets say I am using very simple script
to calculate UNIX time for specified date:

---=======================
#!/usr/bin/perl

use Time::Local;
my ($d, $m, $y);
my $time;

@myYears = ('01/06/2000', '01/06/2015', '01/06/2038', '01/06/3000');

foreach (@myYears) {
($d, $m, $y) = split '/', $_;
$time = timelocal(0,0,0,$d,$m-1,$y);
printf "%ld\n\r", $time;
}

---=====================

It will produce the following output:

959832000
1433131200
2158977600
32516740800

I am not sure if its take leap second consideration. Most likely not.
And that means its only accurate for the present and pas time. Right ?
For my clock I already implement the function for the leap second and I
am able to add/remove number of seconds from the time I receiving from
GPS or any other source. But it will be more inetersting if clock could
do it "automagically" and shows me that famous "60" number without human
interaction. Any advise for this ? Thanks !

Regards,

V.P.

On , Tom Van Baak wrote:

--
WBW,

V.P.

The difference between GPS time and UTC (due to leap seconds) is
broadcast in the GPS navigation message[1] so all but the most poorly
designed GPS modules should take care of it and output the correct UTC
time.

I'm not going to get into the mess of unix epoch time.  Basically,
it's not a continuous time scale.  There is some information on the
wikipedia page[2], and plenty of discussion on various mailing lists
such as LEAPSECS.

Henry

[1] Specifically, page 18 of subframe 4 - see IS-GPS-200G page 112,
114 and 119-121.
[2] https://en.wikipedia.org/wiki/Unix_time#Leap_seconds

On Tue, Jan 6, 2015 at 1:01 PM, d0ct0r time@patoka.org wrote:

Here's a nixie clock using javascript. It includes a leap second count down which is now active:
http://leapsecond.com/java/nixie.htm

For your project, any GPS module with 1PPS output is a start. Those with NMEA output are problematic. First, there is no advanced notice that a leap second is pending in standard NMEA sentences. Second, some GPS receivers cheat and output a double 23:59:59 or a double 00:00:00 instead of a true 23:59:60 for a positive leap second. Third, the NMEA timestamp follows the 1PPS instead of leads so you only find out too late that there was a leap second.

To get it right, you'll need two external switches that the user can flip to indicate that a leap second should be applied at the end of the current calendar month and what "sign" the leap second is (insert or delete). The state should be reset after the leap second to avoid an accidental leap second the next day or next month. This is what modern atomic clocks like the hp 5071A or FTS 4065B do.

Better GPS receivers, like Oncore, M12, TBolt, and ublox provide a binary interface and from this you get the leap second warning bits without resorting to switches. This is the preferred "automagic" solution.

Note also that leap seconds are applied at UTC midnight, so if your Nixie clock displays local time, including daylight saving time, you have to take this into account. For me the local leap second is 15:59:60 PST or 16:59:60 PDT.

The UNIX epoch time and leap seconds is a can of worms. It's best to think of time_t as a vintage, convenient, compact, binary integer encoding to/from a readable, portable, ascii string yyyy-mm-dd hh:mm:ss that works most of the time except when it doesn't. Your perl script will work, except for leap seconds.

All the external RTC modules I've seen are incompatible with leap seconds. The same is true for any analog clock display (wrist watches, wall clocks).

Big Ben handles leap seconds by adjusting the pendulum rate by an equivalent of 12 ppm a day before the leap. Google handles leap seconds in a similar way:
http://news.bbc.co.uk/2/hi/science/nature/7792436.stm
http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html

Most computers don't know if there will be a leap second (and don't care). If you run NTP you get some low level support for leap seconds, but even still most UNIX and Windows software is incapable of displaying or parsing the 23:59:60 leap second correctly.

/tvb

----- Original Message -----
From: "d0ct0r" time@patoka.org
To: "Discussion of precise time and frequency measurement" time-nuts@febo.com
Sent: Tuesday, January 06, 2015 1:01 PM
Subject: Re: [time-nuts] June 30 2015 leap second

On 7 Jan 2015 00:23, "d0ct0r" time@patoka.org wrote:

necessary to add leap seconds ?

During the event, the kernel raw time (assuming UTC) will go from
23:59:58.999999999 straight to 00:00:00.000000000 when removing a leap
second, and when inserting one, Linux for example will go
23:59:59.999999999 to 23:59:59.000000000 again. The time formatting library
functions (aware of leap and time zones) will turn the latter into xx:59:60.

As to how the computer knows - some time sync software (NTPd, PTPd etc.),
which is made aware of the event from upstream, needs to tell the kernel
about this - on systems with the kernel NTP API like Linux, BSDs and
others, this is done by setting a respective STA_INS or STA_DEL status flag
with ntp_adjtime() or adjtimex(). This can be done in kernel up to 24 hours
in advance. When either of the two flags is set, the kernel will trigger
the leap event in the last seconds of the current day. GPS should announce
the pending leap second not long after the IERS announcement. I haven't
checked my clocks yet but it may already be out there.

I haven’t looked at the raw data, but using the windows apps:

a Trimble Resolution SMT is showing the leap pending
a Motorola UT+ is not.
lady heather is not

u-Center does not appear to provide the status for Ublox receivers.

Henry,

This is not quite true. First, page 18 of subframe 4 is only broadcast every 12.5 minutes so on a cold start worst case you wait up to 12.5 minutes before the receiver can reliably switch from GPS time to UTC time. This would not likely be an issue for the OP since his clock would keep the GPS receiver powered-on.

Second, the OP is building a clock. A precise clock needs a 1PPS and it needs to know what date-time that 1PPS will be. The NMEA sentences only tell you what date-time the 1PPS was. This is the crux of the problem. Two solutions: 1) relax the requirements of the clock and allow it to display NMEA time, which will be late by tens to hundreds of ms. This also assumes the NMEA implementation of the receiver outputs hh:59:60 (many don't). Or 2), use proprietary binary messages from the receiver to get advanced warning of a pending leap second event and then role your own leap second special case code. The latter solution has a rare timing window if you turn on the clock too close to the leap second itself.

/tvb

I'm not sure there's any computer time package that correctly disambiguates
23:59:59 vs 23:59:60 in UTC timestamps in a general purpose way. Some
software simply rejects 23:59:60 UTC as invalid, some will quietly map it
to 23:59:59 effectively making those two seconds impossible to distinguish.

There are important systems in the world, those that genuinely have to
distinguish between those two seconds, that do all timekeeping in TAI or
GPS timescales instead of UTC. I think the Olsen timezone database/library
does support TAI. I don't know if the Olsen timzone library supports GPS.

V.P., since you mention Perl and leap seconds, I'd like to point out that
there's a very useful Perl library for computing delta times around
leapsecond jumps:
http://search.cpan.org/~drolsky/DateTime-1.12/lib/DateTime/LeapSecond.pm

This particular library is useful if you need to know the correct delta
time between UTC timestamps but have chosen to ignore the ambiguity problem
of correctly marking the leapsecond itself.

The "newest announced leap second" is not in the table of leapseconds built
into the code yet, but it's a simple matter to add it (cut and paste from
the IPERS).

Tim.

On Tue, Jan 6, 2015 at 4:01 PM, d0ct0r time@patoka.org wrote:

I couldn't help noticing that Debian just issued an update
to tzone, so that means Linux systems now know about the
leap second.

-Chuck Harris

Tim Shoppa wrote:

Tim,

I was using perl as a tool to calculate UNIX time. As my project based
on STM32 MCU, I have no option to use time libraries. And I dont' think
its applcable for my project. I am thinking what exactly of that UNIX
time is. Looks like its using simple constants, like we have 86400
seconds per day, we have 365/366 days per year. And we have certain
"leap years" with strict rule to identify it. For the clock to use on a
desk, its should be sufficient to avoid confusion with rest of the
world. ;-) In the other words, looking to current UNIX time we could
identify the current date/time as most people see it. But its give us
zero info about actual number of seconds passed since Thursday, 1
January 1970, 00:00:00.

Regards,
V.P.

Hi Chuck,

"Linux systems now know about the leap second" -- this is a very dangerous assumption. And one reason why leap seconds have gotten out of hand the past decade.

Just because you observe one tz update from Debian does not imply that all "Linux systems" on planet earth (or in space) magically know about leap seconds. There must be millions (billions?) of embedded or isolated systems -- from web servers to desktops to military systems to gadgets to Raspberry Pi's to mobile phones, that have not, and will not ever receive this update.

/tvb

Tom Van Baak wrote:

And that's where the new tzdist protocol comes into the game, which can
be used to supply leap second information to time servers which need
to send leap second warnings to their clients.

Systems which are simply time clients can receive the leap second
warning via the usual protocols like NTP or PTP/IEEE1588. Of cours it
must be sure that the information is also evaluated by the client
software.

Martin

Reading about "leap seconds" for the past two days, I found that common
solution for it - just encode "leap second event" proactively and wait
for it.
Of course that possible only if device has that option. For example,
BC637PCI has a menu item "7. Program Leap Event Seconds". Which I did.

Now, if I do the request for time settings, its shows me following:

Time Settings:

Mode                          : GPS
Time Format                    : Binary
Year                          : 2015
Local Offset                  : 0.0
Propagation Delay              : 0
Current Leap Seconds          : 16
Scheduled Leap Event Time      : 1435708799
Scheduled Leap Event Flag      : Insertion
GPS Time Format                : UTC Format
IEEE Daylight Savings Flag    : Enable

"Scheduled Leap Event Time" - is so-called UNIX time. However, I am not
sure where its take number "16" (Current Leap Seconds). Its definitely
was not programmed there by me.
Concerning of my clock project, I am thinking about best approach how to
set up leap second procedure. I mean which time exactly I'll need to do
correction for my clock (set time on RTC module). There is two options,
I think. One: to reset RTC at July 1, 00:00:00 and set it back to June
30, 23:59:00. Or, at July 1, 00:00:01, set RTC back to July 1 00:00:00
and then at July 1 00:00:01 reset RTC with occurrance of raising edge of
1PPS. I would prefer to play with July 1, because in this case I don't
need to do much calculations to transfer RTC time to number of seconds,
decrement it by 1 second, transfer it back to BCD format and write it
back to RTC. Instead, I'll need just read/write RTC register which keeps
number of seconds inside.

Regards,
Vlad

--
WBW,

V.P.

Correct me if I'm wrong, but as I understand it the tzfile in the
tzone package is not used to update the system time - that relies on
NTP or similar.  Rather, the leap second info in the tzone files is
made available for applications to use, primarily for calculating time
differences in the past.

Henry

On Fri, Jan 9, 2015 at 6:17 AM, Tom Van Baak tvb@leapsecond.com wrote:

On Fri, Jan 9, 2015 at 3:21 PM, Martin Burnicki
martin.burnicki@burnicki.net wrote:

Indeed, they can. Even when there hasn't been a leap-second.
Practically all internet (and otherwise?) time distribution is
unauthenticated, the leap second itself is unauthenticated.

It's fragile enough that there have been accidental false leap-second events.

... one of many reasons I'd prefer leap seconds went away though I've
personally had great fun observing them in the past. (and, I suspect,
they may have been one of the first reasons I became interested in
precise time keeping).

d0ct0r wrote:

16 s is the current difference between GPS system time and UTC, which
will increase to 17 after the next leap second. It is part of the UTC
data set broadcasted by the satellites.

I'd expect that in a few days the GPS satellites start broadcasting the
leap second announcement, and then yourGPS receiver should also find out
by itself when the leap second will occur, and what the UTC offset
will be thereafter.

When I looked this morning the sats did't broadcast this information, yet.

As said, once the sats start broadcasting this information your software
should be able to read the time and leap second status from the PCI
card, if the API supports this.

How you can handle this to set your clock depends on the capabilites of
your clock, and its API.

Martin

Gregory Maxwell wrote:

... and even the time you get via NTP or PTP is usually not
authenticated. So you can trust the time and leap second warning, or you
shouldn't trust either.

Yes, for example if there have been GPS receivers which decoded the UTC
parameters incorrectly, and started to announce a leap second when there
wasn't one (end of September).

That's why, for example, ntpd's leap second handling code has been
changed in v4.2.6 to accept a leap second warning only if the warning is
received from a majority of the configured servers.

If you want to be sure you can also provide ntpd with a leap second file
which is then (in current versions) considered as authentic source for
leap second information.

Martin

This is an issue indeed. Here is what I get from MySQL Data Base support
site:

Before MySQL 5.0.74, if the operating system is configured to return
leap seconds from OS time calls or if the MySQL server uses a time zone
definition that has leap seconds, functions such as NOW() could return a
value having a time part that ends with :59:60 or :59:61. If such values
are inserted into a table, they would be dumped as is by mysqldump but
considered invalid when reloaded, leading to backup/restore problems.

As of MySQL 5.0.74, leap second values are returned with a time part
that ends with :59:59. This means that a function such as NOW() can
return the same value for two or three consecutive seconds during the
leap second. It remains true that literal temporal values having a time
part that ends with :59:60 or :59:61 are considered invalid.

Last time it was quite a "pain":

Machines running the mighty Amadeus Altea system were brought down soon
after an extra second was added to Coordinated Universal Time (UTC) at
midnight on Saturday, 30 June. The bonus second was inserted at the
direction of time boffins to keep UTC synchronised with Earth's slowing
rotation.

The Altea system was taken offline for an hour, and staff at Qantas and
Virgin Australia had to check in passengers manually, disrupting flight
plans.

Google's solution looks pretty amazing. The slowing down the clock by
milliseconds as the event approach. May be that an option to play with
Oscillator Aging register. In accordance with data sheet, the Aging
Offset register takes a user-provided value to add to or subtract from
the factory-trimmed value that adjusts the accuracy of the time base.
The Aging Offset code is encoded in two’s complement, with bit 7
representing the SIGN bit and a valid range of ±127. One LSB typically
represents a 0.12ppm change in frequency. The change in ppm per LSB is
the same over the operating temperature range. Positive offsets slow the
time base and negative offsets quicken the time base. So, using that I
could achieve 127x0.12 = 15ppm change.

1s/24h = 1/86400 which is approximately 12ppm. That means that Aging
Offset could slow down my clock for 1 second if I'll apply the maximum
value one day ahead (roughly). I need to do some experiments first. ;-)
Its looks too unreliable for me.

On , Martin Burnicki wrote:

--
WBW,

V.P.

Today, I did the check the settings for my BC637 card. I was surprised
that its overwrite my manual setting for the Leap Event by following
information:

Time Settings:

Mode                          : GPS
Time Format                    : Binary
Year                          : 1995
Local Offset                  : 0.0
Propagation Delay              : 0
Current Leap Seconds          : 16
Scheduled Leap Event Time      : 876614400
Scheduled Leap Event Flag      : Insertion
GPS Time Format                : UTC Format
IEEE Daylight Savings Flag    : Enable

"Sun, 12 Oct 1997 00:00:00 GMT". Its weird. I am going to re-insert it
and will check it again later.

New Time Settings are:

Mode                          : GPS
Time Format                    : Binary
Year                          : 2015
Local Offset                  : 0.0
Propagation Delay              : 0
Current Leap Seconds          : 16
Scheduled Leap Event Time      : 1435708799
Scheduled Leap Event Flag      : Insertion
GPS Time Format                : UTC Format
IEEE Daylight Savings Flag    : Enable

Also, my NTP, which rely on that card,  didn't get the value for leap
second event yet:

ntpq -c rv

associd=0 status=0028 leap_none, sync_unspec, 2 events, no_sys_peer,
version="ntpd 4.2.6p5@1.2349 Mon Sep 22 20:41:39 UTC 2014 (14)",
processor="x86_64", system="Linux/3.2.0-74-generic", leap=00, stratum=1,
precision=-23, rootdelay=0.000, rootdisp=8248.907, refid=BTFP,
reftime=d85e7526.957a1b17  Mon, Jan 12 2015 11:30:30.583,
clock=d85ec544.e1effe31  Mon, Jan 12 2015 17:12:20.882, peer=0, tc=4,
mintc=3, offset=3.757, frequency=-243.698, sys_jitter=0.000,
clk_jitter=1.328, clk_wander=15.616

Regards,
Vlad

--
WBW,

V.P.

d0ct0r wrote:

Why are you wondering? This should be the expected result if your card
receives and decodes the data from the GPS satellites.

I'd expect these will be overwritten again during GPS reception.

However, as far as I can see the UTC parameters currently sent by the
satellites still haven't been updated to reflect the upcoming leap
second, so the date derived from the old week number in this parameter
set is ambiguous. Also the event flag (insertion vs. deletion) can't be
determined from the curent parameters. I'd expect that this is just an
interpreting problem in the user interface.

What would you expect to see? Ntpd accepts and forwards leap second
announcements only one day before the leap second event.

If ntpd would accept a leap second warning right now and set the "leap"
variable accordingly then all its NTP clients would try to insert a leap
second at the end of January. I don't think this is what you want.

By the way, are you sure the driver /127.127.x.0) you are using to let
ntpd get the time from your PCI card supports passing on the leap second
warning to ntpd?

Martin