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

David T. Lewis lewis at mail.msen.com
Mon Mar 21 02:19:14 UTC 2016


On Sun, Mar 20, 2016 at 01:16:45PM -0400, David T. Lewis wrote:
> On Sun, Mar 20, 2016 at 12:39:38AM +0100, Levente Uzonyi wrote:
> > 
> > The loss of the nanosecond part has another side effect. utcMicroseconds 
> > will be a Fraction when the resolution of the parsed input is too high. 
> > This is somewhat compatible, but it makes things slower. E.g.:
> > 
> > '2002-05-16T17:20:45.000000009+01:01' asDateAndTime utcMicroseconds
> > "==> (1021565985000000009/1000)"
> >
> 
> This is an interesting problem.
> 
> The fractional representation of utcMicroseconds seems reasonable to me in
> this case, at least now that you have fixed the bugs that I introduced :-)
> 
> It might however cause issues for Magma and similar applications. I would
> be interested to hear from Chris Muller is that is a problem.
> 
> My expectation would be that microseconds should be the unit of measure
> for time magnitude, but that there should be no limit on precision. Or
> to say it another way, clocks may have ticks, but time itself should be
> thought of as continous. Thus I expect utcMicroseconds to be a Number, but
> not necessarily an Integer.
> 
> Microseconds is a reasonable unit of measure because it is the highest
> level of precision available from the clocks on the Linux, OS X, and
> Windows systems that we use, and because it implies clock accuracy that
> is well beyond the real time measurement capabilities of those platforms.
> 
> As far as I know, the practical use of nanosecond precision in DateAndTime
> would be in the case of adding incremental nanoseconds to the time value
> in order to create the illusion that repeated calls to the system clock
> will always result in monotonically increasing values. If so, then I
> suspect that the same practical result could be achieved by artificially
> incrementing the value in units of milliseconds rather than nanoseconds,
> which would ensure unique integer values.
> 
> After all, it does not seem likely that any application involving a
> database would be querying the system clock at a rate anywhere close to
> a million per second. But I have not actually tried this, so I may be
> misunderstanding the requirement.
>

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.


 


More information about the Squeak-dev mailing list