On Mon, May 26, 2014 at 02:17:47PM +0000, J. Vuletich (mail lists) wrote:
Hi David, Folks,
Quoting "David T. Lewis" lewis@mail.msen.com:
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?
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
Quoting "David T. Lewis" lewis@mail.msen.com:
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
Thanks Dave,
I could run on 64 bits Ubuntu with the VM from squeakvm.org/unix. I'll try the Mac VM when I get the chance to borrow a Mac again.
One thing that seems to be missing is a Windows interpreter with the new primitives, although I don't know if there is a real need for that.
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.
Cheers, Juan Vuletich
vm-dev@lists.squeakfoundation.org