[squeak-dev] UTCDateAndTime updated for Squeak trunk Chronology and Spur (was: UTCDateAndTime updated for Squeak 4.6/5.0)

Levente Uzonyi leves at caesar.elte.hu
Wed Mar 23 16:01:35 UTC 2016


Hi Dave,

On Sun, 20 Mar 2016, David T. Lewis wrote:

>
> I updated the package in Chronology-Core-dtl.14 to provide implementations
> of various strategies for providing monotonically increasing DateAndTime now
> with a utcMicrosecond time base. I am not sure which is the best approach,
> but this shows how any of them can be supported.
>
> The update comment describes the options:
>
> 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.

I think this covers most possible use cases. What I was originally 
thinking about was the addition of another field to hold the nanosecond 
part, since that would have only been set by the image itself, so the 
primitive could still have been used to initialize the rest. That we we 
could have avoided the use of fractions at the cost of having another 
field per object even when there's no need for high accuracy.

One more thing that I noticed is that this primitive still uses the "quick 
but inaccurate" way to get the current time, which only updates every two 
milliseconds (I think once per heartbeat). Eliot has changed primitive 240 
a while ago to always provide the accurate time:

| start end |
start := DateAndTime now.
[ (end := DateAndTime now) = start ] whileTrue.
{ start. end. end - start }
  {2016-03-23T16:53:33.637835+01:00 . 2016-03-23T16:53:33.639844+01:00 . 
0:00:00:00.002009}

| start end |
start := Time utcMicrosecondClock.
[ (end := Time utcMicrosecondClock) = start ] whileTrue.
{ start. end. end - start }
  #(3636201206461149 3636201206461150 1)

Levente

>
>
>
>
>


More information about the Squeak-dev mailing list