Hi Dave,

As I mentioned before, the problem with that primitive is that it doesn't 
update the offset when the time zone changes.
Here's an example from an image which was started in UTC+1, but is in 
UTC+2 right now:

{ Time primPosixMicrosecondClockWithOffset. Locale current primTimezone } 
"#(#(1491158588541139 3600) 120)"

VM info:
/squeak/products/cogspur64linuxht/lib/squeak/5.0-201609151123/squeak
Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.1950]
Unix built on Sep 15 2016 11:24:50 Compiler: 4.6.3
platform sources revision VM: 201609151123 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Thu Sep 15 13:23:12 2016 +0200 $ Plugins: 201609151123 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
CoInterpreter VMMaker.oscog-eem.1950 uuid: b4089b49-1494-49d2-8966-57cba5c92194 Sep 15 2016
StackToRegisterMappingCogit VMMaker.oscog-eem.1950 uuid: b4089b49-1494-49d2-8966-57cba5c92194 Sep 15 2016

Levente

On Sun, 2 Apr 2017, David T. Lewis wrote:

> I think I'm getting myself confused with too many images with different
> DateAndTime flavors. We already have primitiveLocalMicrosecondClock that
> can be called with primLocalMicrosecondClock, which hopefully does the
> same thing as my snippet below.
>
> Dave
>
>
> On Sun, Apr 02, 2017 at 10:48:00AM -0400, David T. Lewis wrote:
>> Or do it like this, which does not require LocalePlugin:
>>
>>   localMicrosecondClockDave
>>       | timeArray |
>>       timeArray := self primPosixMicrosecondClockWithOffset.
>>       ^timeArray first + ((2177452800 + timeArray second) * 1000000).
>> 
>> Dave
>> 
>> 
>> On Sun, Apr 02, 2017 at 02:08:07PM +0200, Levente Uzonyi wrote:
>> > Hi Herbert,
>> > 
>> > This issue was discussed[1] here recently. I suggested[2] a VM change to 
>> > solve this problem, but the same thing can be done on the image side too.
>> > Just change Time class >> #utcMicrosecondClockWithOffset to be:
>> > 
>> > utcMicrosecondClockWithOffset
>> > 	"Answer an array with UTC microseconds since the Smalltalk epoch and 
>> > 	the
>> > 	current seconds offset from UTC in the local time zone."
>> > 
>> > 	| utc currentMinute |
>> > 	utc := self utcMicrosecondClock.
>> > 	currentMinute := utc // 60000000.
>> > 	LastTimeTimeZoneWasUpdated = currentMinute ifFalse: [
>> > 		LastTimeTimeZoneWasUpdated := currentMinute.
>> > 		TimeZoneOffset := Locale current primTimezone * 60 ].
>> > 	^{ utc. TimeZoneOffset }
>> > 
>> > and Time class >> #localMicrosecondClock to be:
>> > 
>> > localMicrosecondClock
>> > 	"Answer the local microseconds since the Smalltalk epoch (January 
>> > 	1st 1901, the start of the 20th century).
>> > 	 The value is derived from the current UTC wallclock time and the 
>> > 	 image's current notion of time zone."
>> > 
>> > 	| utcMicrosecondClockWithOffset |
>> > 	utcMicrosecondClockWithOffset := self utcMicrosecondClockWithOffset.
>> > 	^(utcMicrosecondClockWithOffset at: 2) * 1000000 + 
>> > 	(utcMicrosecondClockWithOffset at: 1)
>> > 
>> > 
>> > LastTimeTimeZoneWasUpdated and TimeZoneOffset should be class variables. 
>> > They don't have to be initialized.
>> > 
>> > Levente
>> > 
>> > [1] 
>> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-March/193594.html
>> > [2] 
>> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-March/193638.html
>> > 
>> > On Sun, 2 Apr 2017, Herbert K?nig wrote:
>> > 
>> > >Hi all,
>> > >
>> > >I have a long running 5.1 image on a Raspi A+ which regularly waits on a 
>> > >Delay.
>> > >
>> > >Raspbian has noticed daylight saving, Squeak not.
>> > >
>> > >Is this expected and what can I do with the running image to make it 
>> > >notice? Except waiting for the monthly crash and restart :-)
>> > >
>> > >
>> > >Cheers,
>> > >
>> > >Herbert
>> > >
>> > >
>> > >
>> 
>> > 
>> 
>>