Re: [squeak-dev] A UTC based implementation of DateAndTime

> Hi David, Folks,
>
> Quoting "David T. Lewis" <[hidden email]>:
>
> >I have been working on a variation of class DateAndTime that replaces its
> >instance variables (seconds offset jdn nanos) with two instance variables,
> >utcMicroseconds to represent microseconds elapsed since the Posix epoch,
> >and
> >localOffsetSeconds to represent the local time zone offset. When  
> >instantiating
> >the time now, A single call primitiveUtcWithOffset is used to obtain these
> >two values atomically as reported by the underlying platform.
> >
> >There are several advantages to this representation of DateAndTime, the
> >most
> >important of which is that its magnitude is unambiguous regardless  
> >of daylight
> >savings transitions in local time zones.
> >
> >This is my attempt to address some historical baggage in Squeak. The VM
> >reports time related to the local time zone, and the image attempts to
> >convert to UTC (sometimes incorrectly). A UTC based representation makes
> >the
> >implementation of time zone tables more straightforward (see for example
> >the Olson time zone tables in TimeZoneDatabase on SqueakMap).
> >...
> >Dave
>
> I very much support this approach. I did a bit of testing of  
> <primitive: 'primitiveUtcWithOffset'> . I found that on a Mac, with  
> 'Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.331] Squeak  
> Cog 4.0.2776' 'Mac OS' 'intel' '1092' (from Eliot's site), the second  
> element I get (time zone offset) is -140473411.
>
> The correct value would be -10800, as answered in Windows. I could not  
> test on Linux yet (could not get the vm to run in Ubuntu 14.04 64 bit  
> :( ).
>
> Any clue on what's wrong on Mac OS?
>
> BTW, which would be the current non-Cog VMs to try?
>

> On Mon, May 26, 2014 at 02:17:47PM +0000, J. Vuletich (mail lists) wrote:
>> Hi David, Folks,
>> ...
>> The correct value would be -10800, as answered in Windows. I could not
>> test on Linux yet (could not get the vm to run in Ubuntu 14.04 64 bit
>> :( ).
>>
>> Any clue on what's wrong on Mac OS?
>>
>> BTW, which would be the current non-Cog VMs to try?
>>
>
> Oops, I mistakenly said that the Cog VMs could be used. But it looks like
> there is a regression or code merge problem of some sort. I'm afraid that
> I was testing with my own locally compiled Cog VM and did not notice the
> problem.
>
> A unix Mac VM from squeakvm.org/unix should demonstrate the correct behavior.
>
> CC to vm-dev list:
>
> Eliot, the fix for this was here (but it seems to have been overridden by
> a more recent change):
>
>    Name: VMMaker.oscog-dtl.286
>    Author: dtl
>    Time: 4 May 2013, 11:29:25.237 am
>    UUID: 8be237d9-7812-4792-9723-90f9cff0c2e9
>    Ancestors: VMMaker.oscog-eem.285
>
>    Replace broken primitiveUtcWithOffset with a version that works.
>
> Dave

>> Additionally, besides getting rid of <primitive: 137>
>> (primLocalSecondsClock that will overflow in 2037), it would be great
>> to stop using <primitive: 135> (primLocalSecondsClock), that overflows
>> every six days. But for this, we would need a new <primitive: 136>
>> (primSignal:atMilliseconds:) as it uses on the same time base. This
>> would enable a serious simplification of Delay.
>>
>
> I think that Eliot is planning to update Squeak to use the microsecond clock
> primitive, which removes any 2037 issues. I'm not sure if that would include
> a change to primSignal:atMilliseconds:
>
> Dave

>
> Quoting "David T. Lewis" <[hidden email]>:
>
> >...
> >>
> >
> >Ian did a build of the Windows VM that should have the necessary support.
> >Try
> >the Squeak4.1.2.2612 VM from http://squeakvm.org/win32/.
>
> That VM fails for
> <primitive: 'primitiveUtcWithOffset'>
> <primitive: 240> primUtcMicrosecondClock
> <primitive: 241> primLocalMicrosecondClock
>
> >One thing to note - if the primitive is not present, DateAndTime will fall
> >back on the old logic, and it should produce reasonable results.
>
> Yes, Cuis already does that... I'd prefer to be able to assume that  
> any future VM will provide <primitive: 'primitiveUtcWithOffset'> and  
> clean the code. Would that asking for too much?

>
> >>Additionally, besides getting rid of <primitive: 137>
> >>(primLocalSecondsClock that will overflow in 2037), it would be great
> >>to stop using <primitive: 135> (primLocalSecondsClock), that overflows
> >>every six days. But for this, we would need a new <primitive: 136>
> >>(primSignal:atMilliseconds:) as it uses on the same time base. This
> >>would enable a serious simplification of Delay.
> >>
> >
> >I think that Eliot is planning to update Squeak to use the microsecond
> >clock
> >primitive, which removes any 2037 issues. I'm not sure if that would
> >include
> >a change to primSignal:atMilliseconds:
> >
> >Dave
>
> I see. But given that the Delay code is fragile and not trivial at  
> all, the advantages of of relying on a clock that never rolls over  
> would be significant.
>
> Please, Eliot, consider this when you work on this code.
>
>
> Cheers,
> Juan Vuletich
>

>  
>> You should expect the following two primitives to be present in all VMs
>> (comments are from the VMM trunk implementations):
>>
>> primitiveUtcWithOffset
>>         "Answer an array with UTC microseconds since the Posix epoch and
>>         the current seconds offset from GMT in the local time zone. An empty
>>         two element array may be supplied as a parameter.
>>         This is a named (not numbered) primitive in the null module (ie the VM)"
>>
>> primitiveUTCMicrosecondClock
>>         "Answer the UTC microseconds since the Smalltalk epoch. The value is
>>         derived from the Posix epoch (see primitiveUTCMicrosecondClock) with a
>>         constant offset corresponding to elapsed microseconds between the two
>>         epochs according to RFC 868."
>>
>  
>
> Since both answer microseconds, then second seems a little confusing.
> Calling them something like #primitivePosixUtcWithOffset and
> #primitiveSmalltalkUtc seems more intention revealing.
>
> cheers -ben
>