[time-nuts] June 30 2015 leap second

[d0ct0r]

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:
> Gregory Maxwell wrote:
>> On Fri, Jan 9, 2015 at 3:21 PM, Martin Burnicki
>> <martin.burnicki at burnicki.net> wrote:
>>> Systems which are simply time clients can receive the leap second 
>>> warning
>>> via the usual protocols like NTP or PTP/IEEE1588.
>> 
>> 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.
> 
> ... 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.
> 
>> It's fragile enough that there have been accidental false leap-second 
>> events.
> 
> 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
> 
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to 
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

-- 
WBW,

V.P.