UTCDateAndTime updated for Squeak 4.6/5.0

> Apologies, this is not right. I was replying from a cell phone and my
> recollection was wrong.
>
> I did at one point implement a #primitiveUtcWithOffset that could receive
> an array of size two as an argument into which the result values are stored,
> instead if allocating the array in the primitive. However, I did *not* commit
> it to VMMaker, and it is not in any currently available VMs.
>
> I think I decided at the time that this approach was dangerous because it
> would invite problems in cases involving multiple processes, where some
> other process might call the primitive using the same array. In that case
> the time value in the array would magically change without the first process
> being aware.

>
> Sorry for the misinformation.
>
> Dave
>
>
> On Sat, Mar 12, 2016 at 11:37:55PM -0500, David T. Lewis wrote:
>> I had the same idea, and I already implemented it in trunk interpreter
>> VMMaker, but it is probably not in oscog yet. I did not add it on the
>> image side, although we could do so if we update the VMs.
>>
>> Dave
>>
>>> I always forget to mention, even though I have had this idea since you had
>>> introduced primitiveUtcWithOffset, that it would be better if the
>>> primitive could take an optional argument to store the values in the first
>>> two slots of it instead of creating a new Array. If it's too much burden
>>> to accept any object, then the argument type can be limited to Array.
>>> This change would make it possible to decrease the GC pressure when many
>>> timestamps are created in a row.
>>>
>>> Levente
>>>
>>> On Sat, 12 Mar 2016, David T. Lewis wrote:
>>>
>>>> On Mon, Mar 07, 2016 at 12:21:38AM -0500, David T. Lewis wrote:
>>>>> On Sun, May 24, 2015 at 12:36:02PM -0400, David T. Lewis wrote:
>>>>>> UTCDateAndTime is a UTC based implementation of class DateAndTime with
>>>>>> one instance variable representing the magnitude of the point in time,
>>>>>> and another representing local time zone offset.
>>>>>
>>>>> I have updated the UTCDateAndTime package to make it loadable in the
>>>>> latest
>>>>> Squeak trunk and Spur.
>>>>
>>>> Has anyone looked at this yet? Any interest?
>>>>
>>>> Dave
>>>>
>>>>>
>>>>> A new Monticello repository is at
>>>>> http://www.squeaksource.com/UTCDateAndTime.
>>>>> The home page (with a new SAR) is at
>>>>> http://wiki.squeak.org/squeak/6197.
>>>>>
>>>>> Starting with an updated trunk image, you can load UTCDateAndTime in
>>>>> two ways:
>>>>>
>>>>> 1) Open the http://www.squeaksource.com/UTCDateAndTime repository, and
>>>>> load
>>>>> the MCZ files in sequence beginning with Chronology-Core-dtl.3.
>>>>>
>>>>> 2) In a preferences browser, in category 'updates' set the 'Update URL'
>>>>> preference to 'http://www.squeaksource.com/UTCDateAndTime', and do
>>>>> world -> help... -> update code from server.
>>>>>
>>>>> The main objective of UTCDateAndTime is to make DateAndTime
>>>>> conceptually
>>>>> simpler, but a happy side effect is that it is also significantly
>>>>> faster
>>>>> than the old implementation.
>>>>>
>>>>> Dave
>>>>
>>>>
>>>
>>
>>
>>
>>
>
>

> On Sun, 13 Mar 2016, David T. Lewis wrote:
>
> >Apologies, this is not right. I was replying from a cell phone and my
> >recollection was wrong.
> >
> >I did at one point implement a #primitiveUtcWithOffset that could receive
> >an array of size two as an argument into which the result values are
> >stored,
> >instead if allocating the array in the primitive. However, I did *not*
> >commit
> >it to VMMaker, and it is not in any currently available VMs.
> >
> >I think I decided at the time that this approach was dangerous because it
> >would invite problems in cases involving multiple processes, where some
> >other process might call the primitive using the same array. In that case
> >the time value in the array would magically change without the first
> >process
> >being aware.
>
> That could only happen if the Array would be shared by multiple processes.
> For example if there were a dedicated class variable to retrieve the
> values from the VM, but that would be nothing but bad design.

> Apologies, this is not right. I was replying from a cell phone and my
> recollection was wrong.
>
> I did at one point implement a #primitiveUtcWithOffset that could receive
> an array of size two as an argument into which the result values are stored,
> instead if allocating the array in the primitive. However, I did *not* commit
> it to VMMaker, and it is not in any currently available VMs.
>
> I think I decided at the time that this approach was dangerous because it
> would invite problems in cases involving multiple processes, where some
> other process might call the primitive using the same array. In that case
> the time value in the array would magically change without the first process
> being aware.
>
> I still think that it is a good idea, but maybe not worth the risk unless
> there is a noticable affect of performance or GC activity. Of course, adding
> the capability to the primitive would not force anyone to actually use it
> that way.
>
> Sorry for the misinformation.
>
> Dave
>
>
> On Sat, Mar 12, 2016 at 11:37:55PM -0500, David T. Lewis wrote:
> > I had the same idea, and I already implemented it in trunk interpreter
> > VMMaker, but it is probably not in oscog yet. I did not add it on the
> > image side, although we could do so if we update the VMs.
> >
> > Dave
> >
> > > I always forget to mention, even though I have had this idea since you had
> > > introduced primitiveUtcWithOffset, that it would be better if the
> > > primitive could take an optional argument to store the values in the first
> > > two slots of it instead of creating a new Array. If it's too much burden
> > > to accept any object, then the argument type can be limited to Array.
> > > This change would make it possible to decrease the GC pressure when many
> > > timestamps are created in a row.
> > >
> > > Levente
> > >
> > > On Sat, 12 Mar 2016, David T. Lewis wrote:
> > >
> > >> On Mon, Mar 07, 2016 at 12:21:38AM -0500, David T. Lewis wrote:
> > >>> On Sun, May 24, 2015 at 12:36:02PM -0400, David T. Lewis wrote:
> > >>>> UTCDateAndTime is a UTC based implementation of class DateAndTime with
> > >>>> one instance variable representing the magnitude of the point in time,
> > >>>> and another representing local time zone offset.
> > >>>
> > >>> I have updated the UTCDateAndTime package to make it loadable in the
> > >>> latest
> > >>> Squeak trunk and Spur.
> > >>
> > >> Has anyone looked at this yet? Any interest?
> > >>
> > >> Dave
> > >>
> > >>>
> > >>> A new Monticello repository is at
> > >>> http://www.squeaksource.com/UTCDateAndTime.
> > >>> The home page (with a new SAR) is at
> > >>> http://wiki.squeak.org/squeak/6197.
> > >>>
> > >>> Starting with an updated trunk image, you can load UTCDateAndTime in
> > >>> two ways:
> > >>>
> > >>> 1) Open the http://www.squeaksource.com/UTCDateAndTime repository, and
> > >>> load
> > >>> the MCZ files in sequence beginning with Chronology-Core-dtl.3.
> > >>>
> > >>> 2) In a preferences browser, in category 'updates' set the 'Update URL'
> > >>> preference to 'http://www.squeaksource.com/UTCDateAndTime', and do
> > >>> world -> help... -> update code from server.
> > >>>
> > >>> The main objective of UTCDateAndTime is to make DateAndTime
> > >>> conceptually
> > >>> simpler, but a happy side effect is that it is also significantly
> > >>> faster
> > >>> than the old implementation.
> > >>>
> > >>> Dave
> > >>
> > >>
> > >
> >
> >
> >
> >

> > On 15.03.2016, at 02:50, David T. Lewis <[hidden email]> wrote:
> >
> > Urk. Sorry for the confusion, but I was looking at the wrong image and I see
> > now that my original statement was correct:
> >
> >   "I had the same idea, and I already implemented it in trunk interpreter
> >   VMMaker, but it is probably not in oscog yet. I did not add it on the
> >   image side, although we could do so if we update the VMs."
> >
> > This is in the trunk VMM (interpreter VM), though not in Cog/Spur yet. Better
> > yet, it already works with Levente's idea (see below) of passing the DateAndTime
> > instance to the primitive. No further changes to the primitive are needed to
> > do this.
> >
> > Therefore the following works in a Squeak 4.6 image with UTCDateAndTime loaded,
> > and running on an interpreter VM:
> >
> >  DateAndTime>>initializeFromPrimitive
> > ^Time primPosixMicrosecondClockWithOffset: self
> >
> >  DateAndTime basicNew initializeFromPrimitive ==> 2016-03-14T21:38:49.81355-04:00
> >
> > So I think this is a very good idea that just needs a couple of minor VM
> > updates to make it available.
> >
> > Dave
> >
> >
> > On Sun, Mar 13, 2016 at 03:03:55PM -0400, David T. Lewis wrote:
> >> Apologies, this is not right. I was replying from a cell phone and my
> >> recollection was wrong.
> >>
> >> I did at one point implement a #primitiveUtcWithOffset that could receive
> >> an array of size two as an argument into which the result values are stored,
> >> instead if allocating the array in the primitive. However, I did *not* commit
> >> it to VMMaker, and it is not in any currently available VMs.
> >>
> >> I think I decided at the time that this approach was dangerous because it
> >> would invite problems in cases involving multiple processes, where some
> >> other process might call the primitive using the same array. In that case
> >> the time value in the array would magically change without the first process
> >> being aware.
> >>
> >> I still think that it is a good idea, but maybe not worth the risk unless
> >> there is a noticable affect of performance or GC activity. Of course, adding
> >> the capability to the primitive would not force anyone to actually use it
> >> that way.
> >>
> >> Sorry for the misinformation.
> >>
> >> Dave
> >>
> >>
> >> On Sat, Mar 12, 2016 at 11:37:55PM -0500, David T. Lewis wrote:
> >>> I had the same idea, and I already implemented it in trunk interpreter
> >>> VMMaker, but it is probably not in oscog yet. I did not add it on the
> >>> image side, although we could do so if we update the VMs.
> >>>
> >>> Dave
> >>>
> >>>> I always forget to mention, even though I have had this idea since you had
> >>>> introduced primitiveUtcWithOffset, that it would be better if the
> >>>> primitive could take an optional argument to store the values in the first
> >>>> two slots of it instead of creating a new Array. If it's too much burden
> >>>> to accept any object, then the argument type can be limited to Array.
> >>>> This change would make it possible to decrease the GC pressure when many
> >>>> timestamps are created in a row.
> >>>>
> >>>> Levente
> >>>>
> >>>> On Sat, 12 Mar 2016, David T. Lewis wrote:
> >>>>
> >>>>> On Mon, Mar 07, 2016 at 12:21:38AM -0500, David T. Lewis wrote:
> >>>>>> On Sun, May 24, 2015 at 12:36:02PM -0400, David T. Lewis wrote:
> >>>>>>> UTCDateAndTime is a UTC based implementation of class DateAndTime with
> >>>>>>> one instance variable representing the magnitude of the point in time,
> >>>>>>> and another representing local time zone offset.
> >>>>>>
> >>>>>> I have updated the UTCDateAndTime package to make it loadable in the
> >>>>>> latest
> >>>>>> Squeak trunk and Spur.
> >>>>>
> >>>>> Has anyone looked at this yet? Any interest?
> >>>>>
> >>>>> Dave
> >>>>>
> >>>>>>
> >>>>>> A new Monticello repository is at
> >>>>>> http://www.squeaksource.com/UTCDateAndTime.
> >>>>>> The home page (with a new SAR) is at
> >>>>>> http://wiki.squeak.org/squeak/6197.
> >>>>>>
> >>>>>> Starting with an updated trunk image, you can load UTCDateAndTime in
> >>>>>> two ways:
> >>>>>>
> >>>>>> 1) Open the http://www.squeaksource.com/UTCDateAndTime repository, and
> >>>>>> load
> >>>>>> the MCZ files in sequence beginning with Chronology-Core-dtl.3.
> >>>>>>
> >>>>>> 2) In a preferences browser, in category 'updates' set the 'Update URL'
> >>>>>> preference to 'http://www.squeaksource.com/UTCDateAndTime', and do
> >>>>>> world -> help... -> update code from server.
> >>>>>>
> >>>>>> The main objective of UTCDateAndTime is to make DateAndTime
> >>>>>> conceptually
> >>>>>> simpler, but a happy side effect is that it is also significantly
> >>>>>> faster
> >>>>>> than the old implementation.
> >>>>>>
> >>>>>> Dave
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >
>
>

> On Sat, Mar 12, 2016 at 08:48:21PM +0100, Levente Uzonyi wrote:
>> Hi Dave,
>>
>> I ran the tests and found that there are three types of failures.
>> 1. Some tests assume that the default offset is #localOffset. I don't
>> think it's correct, but that's how is it in Trunk.
>
> There are 10 failing tests in my image. These are cases in which either
> I was uncertain how to handle the issue, or where I thought that the
> current behaviour in trunk may be wrong.
>
>> 2. Hashes have changed. This implies that HashedCollections containing
>> DateAndTime instances as key will have to be rehashed. In the base Trunk
>> image there are appear to be no such HashedCollections, but not rehashing
>> such collections will break images with custom packages in them after
>> update.
>
> I am not expert in this area at all. But part of the update process
> (in the MC postscripts) finds all instances of the old style DateAndTime,
> and becomes them into the new ones. Would the HashedCollections contianing
> DateAndTime instances as key still require rehash in that case?

>
> Related to DateAndTime>>hash, I would also like to ask for guidance as
> to how DateAndTime>>= should be defined. Maybe this is an ANSI Smalltalk
> question, but I was not sure if we should be thinking of DateAndTime as
> a magnitude, such that two instances are equal if their utcMicroseconds
> are the same? Or are two instances equal if they have the same magnitude
> and also the same localOffsetSeconds?
>
> I implemented the first approach (two instances are #= if they represent
> the same UTC time, regardless of timezone). There may be use cases
> where the other approach makes sense. But my thinking was that when
> comparing two instances of DateAndTime, they should not be considered
> the same unless they both represent the same point in time, hence UTC
> time regardless of the time zone in which the instance was created.

>
>> 3. Loss of resolution and strict monotonicity. In Trunk [DateAndTime now <
>> DateAndTime now] is always true. This is possible because DateAndTime has
>> nanosecond resolution, but the source clock only has microsecond
>> resolution, and our machines are so slow that it takes more than a
>> nanosecond to execute the primitive. All these allow us to use the
>> sub-microsecond part of the timestamp to create intermediate strictly
>> monotonic values.
>>
>
> To be honest, I do not fully recall the rationale for this. One
> important case is that of the system clock being set back due to
> ntp synchronization. Fiddling with the nanoseconds number to make
> it appear as if the OS had reported an increase in time (when in
> fact it did not) seems questionable to me, but I know that it was
> done for some good reason. I do remember the discussions, so I
> should look back through the squeak-dev archives and find out the
> reason this was done.

>
>> Levente
>>
>
> Thanks very much for looking at this. I added you and Chris Muller as
> developers on the UTCDateAndTime repository on squeaksource.com in case
> you want to make any changes.
>
> Much appreciated,
>
> Dave
>
>
>

> Hi Dave,
>
> I finally had some time to dig into the code and the tests.
>
> On Sun, 13 Mar 2016, David T. Lewis wrote:
>
> >On Sat, Mar 12, 2016 at 08:48:21PM +0100, Levente Uzonyi wrote:
> >>Hi Dave,
> >>
> >>I ran the tests and found that there are three types of failures.
> >>1. Some tests assume that the default offset is #localOffset. I don't
> >>think it's correct, but that's how is it in Trunk.
> >
> >There are 10 failing tests in my image. These are cases in which either
> >I was uncertain how to handle the issue, or where I thought that the
> >current behaviour in trunk may be wrong.
> >
> >>2. Hashes have changed. This implies that HashedCollections containing
> >>DateAndTime instances as key will have to be rehashed. In the base Trunk
> >>image there are appear to be no such HashedCollections, but not rehashing
> >>such collections will break images with custom packages in them after
> >>update.
> >
> >I am not expert in this area at all. But part of the update process
> >(in the MC postscripts) finds all instances of the old style DateAndTime,
> >and becomes them into the new ones. Would the HashedCollections contianing
> >DateAndTime instances as key still require rehash in that case?
>
> Yes, it is. When their hash changes, these objects will not be found in
> such collections.
>
> >
> >Related to DateAndTime>>hash, I would also like to ask for guidance as
> >to how DateAndTime>>= should be defined. Maybe this is an ANSI Smalltalk
> >question, but I was not sure if we should be thinking of DateAndTime as
> >a magnitude, such that two instances are equal if their utcMicroseconds
> >are the same? Or are two instances equal if they have the same magnitude
> >and also the same localOffsetSeconds?
> >
> >I implemented the first approach (two instances are #= if they represent
> >the same UTC time, regardless of timezone). There may be use cases
> >where the other approach makes sense. But my thinking was that when
> >comparing two instances of DateAndTime, they should not be considered
> >the same unless they both represent the same point in time, hence UTC
> >time regardless of the time zone in which the instance was created.
>
> As we discussed this at the last board meeting, the right thing is to use
> UTC time only both for #hash and #=, so this is correct.
>
> >
> >>3. Loss of resolution and strict monotonicity. In Trunk [DateAndTime now <
> >>DateAndTime now] is always true. This is possible because DateAndTime has
> >>nanosecond resolution, but the source clock only has microsecond
> >>resolution, and our machines are so slow that it takes more than a
> >>nanosecond to execute the primitive. All these allow us to use the
> >>sub-microsecond part of the timestamp to create intermediate strictly
> >>monotonic values.
> >>
> >
> >To be honest, I do not fully recall the rationale for this. One
> >important case is that of the system clock being set back due to
> >ntp synchronization. Fiddling with the nanoseconds number to make
> >it appear as if the OS had reported an increase in time (when in
> >fact it did not) seems questionable to me, but I know that it was
> >done for some good reason. I do remember the discussions, so I
> >should look back through the squeak-dev archives and find out the
> >reason this was done.
>
> It comes handy in many situations where uniqueness is a must. E.g.
> creating file names, storing them in a database. I don't know why it was
> added originally.
>
> 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)"
>
> I found two other issues:
>
> DateAndTime class >> #date:time: ignores the nanoseconds from the time
> argument. This is present in the Trunk as well, but no test fails, because
> in Trunk TimeStamps have their nanoseconds part cleared (in a very
> inefficient way).
>
> The other issue is that DateAndTime >> #getSeconds returns a fraction,
> which contains the nanosecond part as well. This makes DateAndTime >>
> #asTime return a Time instance which has its nanoseconds part doubled.
> I simply changed #/ to #// in #getSeconds to work that around. This
> also satisfied the expectations of all other senders of #getSeconds, but
> then it turned out to be the same as #getWholeSeconds.
> Since #getSeconds is a replacement for the original seconds variable (if
> I'm not mistaken), I think it's safe to do this change and replace sends
> of #getWholeSeconds to #getSeconds.
>
> I found that I'm a developer on the project, so I have uploaded a new
> version with the changes described above + some optimizations.
>
> About some #FIXMEs:
> #offset: is plain wrong according to its comment. It should simply create
> a copy with the new offset and the same utcMicrosecond value. Just like
> how #utcOffset: does. We should keep one or the other but not both.
>
> Levente
>
> >
> >>Levente
> >>
> >
> >Thanks very much for looking at this. I added you and Chris Muller as
> >developers on the UTCDateAndTime repository on squeaksource.com in case
> >you want to make any changes.
> >
> >Much appreciated,
> >
> >Dave
> >
> >
> >

> 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.

> On 23.03.2016, at 23:48, David T. Lewis <[hidden email]> wrote:

>
> On Sun, 20 Mar 2016, David T. Lewis wrote:
> >
> >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)
>

> On Wed, Mar 23, 2016 at 4:51 PM, David T. Lewis <[hidden email]> wrote:
>
> > On Wed, Mar 23, 2016 at 04:22:21PM -0700, Eliot Miranda wrote:
> > >
> > > Turns out this isn't needed for Cog.  I have ioLocalSecondsOffset which
> > > answers a value determined at start-up and only changed
> > > via ioUpdateVMTimezone, which itself is controlled by
> > > primitiveUpdateTimezone, #243.  So ioUTCMicroseconds is all that's needed
> > > to get at the clock and timezone atomically.
> >
> > If it is updated at start-up, then it's wrong. Think of daylight savings
> > time transitions.
> >
>
> So update it automatically once a second or some such?
>

> Hi Levente,
>
> On Wed, Mar 23, 2016 at 05:01:35PM +0100, Levente Uzonyi wrote:
>>
>> On Sun, 20 Mar 2016, David T. Lewis wrote:
>> >
>> >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.
>
> I'm actually quite happy with the idea of the value being a Number that
> is an Integer for all reasonable values that could ever be supplied by
> the VM, but that might be a Fraction if we want to represent time values
> at some higher precision. Mainly I like it because it seems good conceptually
> to think of time as continuous, and not as discreet ticks of a clock.
>
> It also works well computationally, because the normal case uses integer
> values (immediates in 64-bit Spur), and because Fractions involve two
> integer values, which presumably would be no worse than a design that
> added another field. But given that none of our computers or VMs can
> report time to a precision greater than microseconds, I think that we
> can safely ignore the issue for another 20 years or so ;-)

> On Thu, Mar 24, 2016 at 7:12 AM, David T. Lewis <[hidden email]> wrote:
> >
> > I'm actually quite happy with the idea of the value being a Number that
> > is an Integer for all reasonable values that could ever be supplied by
> > the VM, but that might be a Fraction if we want to represent time values
> > at some higher precision. Mainly I like it because it seems good conceptually
> > to think of time as continuous, and not as discreet ticks of a clock.
> >
> > It also works well computationally, because the normal case uses integer
> > values (immediates in 64-bit Spur), and because Fractions involve two
> > integer values, which presumably would be no worse than a design that
> > added another field. But given that none of our computers or VMs can
> > report time to a precision greater than microseconds, I think that we
> > can safely ignore the issue for another 20 years or so ;-)
>
> Its not so far away. Three contemporary examples...
>
> * Systems that synchronise time from GPS do so "typically well within
> 40 nanoseconds" [1]
>
> * The distributed clock of EtherCAT networks synchronises nodes to
> better than 100ns. See slide 23 [2] and figure 7 [3].
>
> * IEEE 1588 provides synchronised network time "in the range of
> +/-200ns between some nodes and even +/-50ns and less between the
> better ones." [4]
>
> This matters for applications like financial trading, motion control
> and sequence-of-event logging on industrial plants.  Maybe not
> Smalltalk's bread and butter, but the last two are areas I'd like to
> use it at a co-ordinator level.
>
> cheers -ben
>
> [1] http://gpsinformation.net/main/gpstime.htm
> [2] https://ece.uwaterloo.ca/~sfischme/rate/Joey-Stubbs-Ethercat.pdf
> [3] http://www.iestcfa.org/bestpaper/wfcs10/wfcs10_bpa.pdf
> [4] https://home.zhaw.ch/~wei/IEEE1588/embedded_World_05_Contribution_final.pdf