Greyware Automation Products, Inc.
Greyware Automation Products, Inc.   
     Home    Products    Store    Downloads    Customer Service    Site Search    
Log in  or   Create an account now -- FREE!        
Kb > FAQ: How does Domain Time handle leap years and leap seconds?

KB2012.125
FAQ: How does Domain Time handle leap years and leap seconds?

This article applies to Domain Time II.

Last Updated: 3 June 2015

Question

    FAQ: How does Domain Time handle leap years and leap seconds?

Answer

    Leap Years
    February 29th, occurring only in leap years, does not require any special handling under Windows operating systems. The calendar for that year simply includes the extra day, and all internal calculations take account of it. Since time protocols exchange information using UTC or TAI, both of which are a count of seconds since that protocol's epoch, the date is derived from the time, rather than specified. Domain Time manages the clock using UTC, and Windows is responsible for converting the count of seconds to the date that is displayed.

    Leap Seconds
    As of version 5.1 of Domain Time, leap seconds are scheduled to be applied on the last day of the month, immediately after the 60th second of the 59th minute of the 23rd hour UTC. By convention, leap seconds are applied to all clocks in the world at the same moment. Previous versions of Domain Time did not account for leap seconds, but merely applied the changed time as a normal correction during the first time check after the leap second occurred. The remainder of this document discusses the behavior of Domain Time II version 5.x and later.

    Domain Time learns about leap seconds from time sources announcing leap seconds (generally a GPS-connected source using either NTP or PTPv2). If a Domain Time Server knows of an upcoming leap second, it will inform clients being served by NTP and, as of version 5.2.b.20110601, the DT2 protocol. If a Domain Time Server is configured to be free-running (that is, serving the time without using any time sources), it will not know about pending or past leap seconds.

    NOTE: If Domain Time is configured to obtain its time from multiple sources, all sources must agree on the upcoming leap second. Domain Time will reject leap seconds if its sources do not agree with each other.

    Leap second insertions (a minute with 61 seconds) are supposed to generate a time sequence like this:

      11:59:00 UTC
      11:59:01 UTC

      11:59:59 UTC
      11:59:60 UTC
      < this is the extra second
      00:00:00 UTC

      The Windows operating systems are not currently capable of having a minute with 61 seconds, so the 60th second is simply repeated. Domain Time accomplishes this by slewing the clock backward one full second at the designated UTC time. Since slewing is used, it takes approximately two full seconds of wall-clock time for one second of computer time to elapse. At the end of the two-second adjustment, the wall-clock time and computer time will again match (assuming the wall clock has inserted its own leap second). Within the computer, time continues to progress (it doesn't go backward), but at a slower than normal rate, until the leap second has been inserted. Effectively, this means that processes will see the 60th second repeated:

      11:59:00 UTC
      11:59:01 UTC

      11:59:59 UTC
      11:59:59 UTC
      < this is the extra second
      00:00:00 UTC

    Due to the nature how leap seconds are calculated, a leap second deletion (a minute with only 59 seconds) has never occurred. However, NTP and PTPv2 are both capable of signaling a pending deletion if necessary, and Domain Time handles it much the same way as it handles an insertion. Instead of slowing the computer down temporarily, it speeds the computer up. The last minute of the day will end up with only 59 seconds. Processes will see the time slewing forward for approximately half of a second, after which wall clocks and computer time will again match.

    Logs and Confirmation
    Administrators can check NTP sources for pending leap seconds using the command-line NTPCheck utility provided with Domain Time:

      ntpcheck host -raw shows the leap flags of any NTP server, including Domain Time Server (if serving NTP is enabled) or Domain Time Client (if the NTP listener is enabled)

    where "host" is either an IP address or a DNS name. NTP servers may begin showing a pending leap second as early as a month before it is due, or as late as the day of. Since leap seconds are defined as occurring on the last day of the month, and the flag does not include date information, the flag cannot be set more than a month ahead. Some servers will only set the flag on the day the insertion is due. Query your hardware vendor for details on your particular model's behavior. The software implementation of NTP typically uses a file referenced in ntpd.conf to specify the date of upcoming leap seconds. Hardware clocks usually get the information from GPS or radio.

    PTPv2 servers normally get their leap second information from GPS and require no configuration.

    Domain Time notes the leap flag when it queries its time sources. If all sources agree that a leap second (either insertion or deletion) is due, Domain Time calculates the offset between the current time and the last second of the month, and schedules an event for that exact time in UTC. Corrections to the clock between the scheduling and the event are automatically accounted for by the operating system, so the event will fire at the desired moment. Domain Time will note the scheduled event in the text log, saying which server informed Domain Time of the upcoming leap, the scheduled time in UTC, and the scheduled time in local time.

    If subsequent time checks reveal a disagreement with the previously-scheduled event, or all of Domain Time's sources do not agree, the event is cancelled. Domain Time notes this cancellation in its log.

    When the event occurs, Domain Time adjusts the clock as needed, and notes the reason for the adjustment in its log. It then records the time the adjustment was made, and ignores the flag (if still set by any sources) until a minimum of 45 days has passed since the leap second was applied. This prevents duplicated leap seconds caused by servers that fail to clear the flag promptly after the event has passed.

    For PTPv2 (IEEE1588-2008), the TAI-UTC offset is automatically adjusted to compensate for the leap second. PTPv2 grandmasters use a mechanism similar to the NTP leap second pending flags. They will also adjust their own TAI-UTC offsets, so even without leap second scheduling enabled, a machine using PTPv2 as its source will leap correctly.

    Domain Time does not preserve pending leap second information between restarts of the Domain Time service. If a leap second event begins being announced while Domain Time is not running, Domain Time will discover the information when it checks its sources after startup. If a leap second event occurs while Domain Time is not running, the event has already passed and should not be scheduled. Domain Time will account for the extra second at the startup correction.

    You may disable Domain Time's advanced scheduling of leap seconds by unchecking the box on the Advanced tab of the Control Panel applet. If this box is unchecked, then Domain Time will account for the leap second the next time it checks its sources after the leap event has occurred. Correction for the extra second will be handled exactly as if the clock were really off by that amount (i.e., slewing or stepping, based on your configuration).

    If advanced scheduling is disabled, but Domain Time discovers a pending leap second when it queries its sources, it will note in the log that the leap second is pending but not scheduled.

    Leap second log entries are "Information" level. You do not need to change your log to trace or debug to see leap second activity.

My Account  |   Contact Us  |   Feedback to Greyware  |   Privacy Policy  |   Printer-Friendly Version
 
Copyright © 1995-2018 Greyware Automation Products, Inc.  All Rights Reserved
All Trademarks mentioned are the properties of their respective owners.