Use of UTC and offset for system clock (was: [Vm-dev] Re: [squeak-dev] Daily Commit Log)

[John M McIntosh]

On 2010-08-24, at 11:07 AM, David T. Lewis wrote:

> primitiveMicrosecondClock is like primitiveMillisecondClock in that
> it answers a value that rolls over periodically, and it not a measure
> of duration relative to any epoch. The extra precision is of course
> meaningless for any individual call, but apparently is of value when
> taken cumulatively for purposes of profiling. I will have to defer
> to John as to whether it can or should be replaced by
> primitiveUTCMicrosecondClock.

Well from the historical viewpoint the primitiveMillisecondClock would answer a value where zero was either the 
boot time of the machine, the startup time of the app, or some epoch...  In listening to clients over the year's I 
think they want it tied to the "standard" epoch because they do stuff like oh get the date & time, then oh um, grab the 
millisecond clock and tack that onto the SECONDS. That ill defined behaviour isn't quite truthful if the two time values
are using different h/w clocks. 

I note the reason behind the different zero times was because different hardware solutions were used over the years to 
avoid the usually more expensive time/date calculation. But the thrust from the OS vendors has been to move away from 
accessing the hardware directly so you end up with gettimeofday() anyway.. 


>   This approach worked very well for VisualWorks where we
>> got rid of lots of customer problems every 49.7 days (2^32 milliseconds).
>> There has been some concern expressed about the performance impact of l


Ya, I *was* the customer for that particular problem, and I thought it as 24.8 days being a signed integer (somewhere)... 
Nothing like the client's mission critical world-wide choke point server crashing after X days...  
I'll not mention how many years the fix took. 

The workaround was to assign some IT person to restart the app 
every Monday morning at 6:00am so it was part of their weekly task list.



===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================