Behavior change in handling negative system time
Prior to VisualAge Smalltalk 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 (or Summer Time) ends
3. A hardware or software clock synchronizer program makes a negative adjustment to the time
By treating all 3 of these conditions 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 adjustments in the tick counter. For an example of this usage, see the Time class>>#millisecondsToRun: method.
The default values for negative time epsilon are 5 minutes.
Last modified date: 07/02/2019