I have no strong preferences, other than to say that fewer options is
better if possible.

I do need to correct myself - I said in the email below that the current
default clock policy is #monotonicForceNanosecondIncrement, but I meant
to say that #monotonicAllowDuplicates is the default. That is not what
you would want for the use case of forcing unique keys.

Dave


On Wed, Jan 16, 2019 at 05:44:14PM -0600, Chris Muller wrote:
> I agree with #acceptPlatformTime as the default, but can't we keep the
> others around?  #monotonic *definitely* has a use-case (e.g,
> unique-key), and they all sound useful depending on the circumstance
> -- or, at least informative about the properties of #now...
> 
> 
> On Mon, Jan 14, 2019 at 7:48 PM David T. Lewis <lewis at mail.msen.com> wrote:
> >
> > 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)
> > >   !
> > >
> > >
> >
>