Use of UTC and offset for system clock (was: [Vm-dev] Re:
[squeak-dev] Daily Commit Log)
John M McIntosh
johnmci at smalltalkconsulting.com
Tue Aug 24 19:04:26 UTC 2010
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
===========================================================================
More information about the Vm-dev
mailing list