Migration Guide


Behavior change in handling negative system time

Prior to V6.0, the design assumed that if the system time goes backwards, then the system's tick counter must have rolled over to zero. However, there are at least 3 situations that can cause time to go backwards:

  1. The tick counter rolls over to zero
  2. Daylight Savings Time ends
  3. A hardware or software clock synchronizer program makes a negative adjustment to the time

By treating all 3 of these the same, errors were introduced in code that compares successive probes of the system's tick counter. For simplicity, situations 1 and 2 will continue to be treated alike. This introduces (or rather, doesn't eliminate) a once-a-year error.

Situation 3 will be treated as a no-op condition by introducing a time epsilon. Code taking successive probes of the system's tick counter using methods such as millisecondClockValue or microsecondClockValue should make use of this epsilon value (obtained from the CldtConstants pool dictionary entries MillisecondClockValueEpsilon or MicrosecondClockValueEpsilon) to effectively ignore small negative ajustments in the tick counter. For an example of this usage, see Time class>>#millisecondsToRun:.

The default values for negative time epsilon are 5 minutes.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]