Support for Leap Seconds in Emerald Timestamp
Beginning with version 2.0, Emerald Timestamp has tentative support for live leap-second display. That is, during the insertion of the leap second at the end of June 2012 (UTC), the UTC time will read, for example,
A few notes about this support:
- Intervals that span a leap-second event are properly calculated (this has been true since version 1.4 released April 2011).
- The code in question has been well tested under simulation but not with an actual leap second
- NTP servers in the past have not been consistent in returning the correct time after a leap-second event, so the time may revert (or partially revert) when the first sync comes in following the event. It will eventually catch back up to the official time as the NTP servers correct themselves properly, so this will only affect times captured during the period immediately after the leap-second event.
- JD(UTC) will "hold" at the leap-second boundary, because it has no way of representing the intervening time. This is why JD(TT) is recommended to be used in its place, though of course it is referenced to a different standard.
- Similarly, Excel has no way of representing the extra time, so when exporting to an Excel spreadsheet the times like :60.x are represented as being at :00.0 for the next minute. Excel-format intervals are correctly exported.