This article applies to Domain Time II.
Last updated: 1/25/2012
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.
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:60 UTC < this is the extra second
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
11:59:59 UTC < this is the extra second
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
where "source" is either an IP address or a DNS name. NTP servers may begin showing a pending leap second up to a month before it is due. 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 24 hours has passed. This helps prevent duplicated leap seconds caused by servers that fail to clear the flag immediately after the event has passed.
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 |
Copyright © 1995-2013 Greyware Automation Products, Inc. All Rights Reserved
All Trademarks mentioned are the properties of their respective owners.