On Mon, May 26, 2014 at 06:16:03PM +0000, J. Vuletich (mail lists) wrote:
> 
> Quoting "David T. Lewis" <lewis at mail.msen.com>:
> 
> >...
> >>
> >
> >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?

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

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