On Mon, May 26, 2014 at 04:41:10PM +0000, J. Vuletich (mail lists) wrote:
> 
> Quoting "David T. Lewis" <lewis at 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.
> 

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

One thing to note - if the primitive is not present, DateAndTime will fall
back on the old logic, and it should produce reasonable results.

> 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