Thanks Levente for the test update.

All:

For background on Time class>>clockPolicy, below is the explanation from
my original commit notice in the UTCDateAndTime repository.

My personal preference would be to adopt #acceptPlatformTime (currently it
is set to #monotonicForceNanosecondIncrement), and to remove the clock
policy options entirely. I expect that others may have different opinions.

Dave


  Name: Chronology-Core-dtl.14
  Author: dtl
  Time: 20 March 2016, 9:42:49.417923 pm
  UUID: 813fbf89-d8e0-4242-a5e5-9e665c9b8618
  Ancestors: Chronology-Core-ul.13
  
  Implement a variety of policies for incrementing the clock on repeated
  calls to DateAndTime class>>now. It is not clear which policy may be best,
  so provide four variants for experimentation and review. Presumably three
  of the four options can be removed at a later date.
  
  See Time class>>clockPolicy to select a policy. The current clock policy
  is set to #monotonicForceNanosecondIncrement.
  
  The four policies are:
  
  #acceptPlatformTime - Accept the time value provided by the system
  platform, even in this allows time to appear to move backwards when
  the clock is adjusted. Simple, fast, and no hidden side effects.
  
  #monotonicAllowDuplicates - Accept the time value provided by the
  system platform unless it is less that the last clock tick. This
  protects for system clock adjustments. Side effects unlikely. Does not
  ensure unique values on repeated calls.
  
  #monotonicForceMicrosecondIncrement - If the time value is less than or
  equal to the value from the last call, force increment by one microsecond.
  This ensures integral values of UTC time, but increments the time value
  by a full microsecond.
  
  #monotonicForceNanosecondIncrement - If the time value is less than or
  equal to the value from the last call, force increment by one nanosecond.
  This it functionally compatible with previous Squeak practice, but is
  computationally expensive and results in time values represented as
  fractions, which might be a problem for some database applications.


On Mon, Jan 14, 2019 at 12:18:42PM +0000, commits at source.squeak.org wrote:
> Levente Uzonyi uploaded a new version of Chronology-Tests to project The Inbox:
> http://source.squeak.org/inbox/Chronology-Tests-ul.15.mcz
> 
> ==================== Summary ====================
> 
> Name: Chronology-Tests-ul.15
> Author: ul
> Time: 14 January 2019, 1:18:04.380862 pm
> UUID: 31a3ca9d-4c54-4034-9d36-9967644e2d87
> Ancestors: Chronology-Tests-dtl.14
> 
> - updated DateAndTimeTest >> #testPrecision to be aware of Time's ClockPolicy
> 
> =============== Diff against Chronology-Tests-dtl.14 ===============
> 
> Item was changed:
>   ----- Method: DateAndTimeTest>>testPrecision (in category 'Tests') -----
>   testPrecision
>   	"Verify that the clock is returning a value with accuracy of better than 1 second.  For now it seems sufficient to get two values and verify they are not the same."
>   
> + 	| originalClockPolicy |
> + 	originalClockPolicy := Time clockPolicy.
> + 	[
> + 		#(
> + 			"#acceptPlatformTime is not listed here, because it doesn't guarantee monotoncity."
> + 			monotonicAllowDuplicates <=
> + 			monotonicForceMicrosecondIncrement <
> + 			monotonicForceNanosecondIncrement <
> + 		) pairsDo: [ :clockPolicy :comparator |
> + 			| first second |
> + 			Time clockPolicy: clockPolicy.
> + 			first := DateAndTime now.
> + 			second := DateAndTime now.
> + 			self
> + 				assert: (first perform: comparator with: second)
> + 				description: ('Clock policy {1} didn''t compare with {2}' format: { clockPolicy. comparator }) ] ]
> + 		ensure: [ Time clockPolicy: originalClockPolicy ]
> - 	self
> - 		assert: (DateAndTime now ~= DateAndTime now)
>   !
> 
>