[time-nuts] June 30 2015 leap second
time at patoka.org
Fri Jan 9 16:55:59 EST 2015
This is an issue indeed. Here is what I get from MySQL Data Base support
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
The Altea system was taken offline for an hour, and staff at Qantas and
Virgin Australia had to check in passengers manually, disrupting flight
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
>>> 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
> 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.
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> and follow the instructions there.
More information about the time-nuts