You should beware that when the millisecond clock wraps is vm version and os dependent. It might not wrap at 9999999... rather some power of two.

On Sep 19, 2004, at 4:37 PM, John Pierce wrote:

Thanks Avi. That seems to work pretty well and gives me what I was looking for. For the time being I am incorporating your change as a separate class (called MillisecondClockOffset) in my Scheduler package to avoid changing DateAndTime. Scheduler is on SM and SqueakSource for anyone who might be interested in it. Of course, DateAndTime class>>now still must be overridden as you did, but that was the only change required to DateAndTime.

So, did you get the sense this change would be never be harvested into the Chronology classes? I find it very useful to have millisecond precision on time now so that things like audit trails can be accurately generated and replayed plus a host of other reasons.

Regards,

John

-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

Ah, right, that's interesting. So the current millisecond clock value should be stored with the offset, and if the clock ever drops below that value, that's a signal that you need to recalibrate.

So how would you recalibrate? You know the value of the millisecondClock when first starting the image, but if it rolls over, what was the max value of the millisecondClock before it rolled over? Is this defined specifically anywhere other than as some power of 2? Is it a signed 4-byte integer? Or is this a platform-specific "pipe sticking up through the floor" problem?

John

On Tuesday 21 September 2004 5:49 pm, Avi Bryant wrote:

You don't need to know the max value - you just need to know that it has rolled over (and you have to make sure that you check frequently enough that you'll catch every rollover).  Then you recalibrate from scratch, ie, by repeatedly watching for the second clock to change and recording the millisecond clock value at that point.  Of course, this means that every once in a while "DateAndTime now" will be very slow; need to deal with that somehow.

Actually, I deal with this all the time in my microcontroller code, and it's simple to make it fast.

If you assume that: - the millisecond clock rate is accurate (which it had better be!) - the millisecond clock is an unsigned number, limited to SmallInteger maxVal / 2 (which it is; it's masked with 16r1FFFFFFF)

then you can do this:

globals:

BigMillisecondClock is an arbitrary-precision integer

LastMillisecondClock is a SmallInteger, a copy of the millisecondClock the last time we looked at it

MaxMillisecondClockValue is the maximum value of the millisecond clock on this platform

from time to time (that is, more often than MaxMillisecondClockValue):

now := Time millisecondClockValue. delta := now - LastMillisecondClock. delta < 0 ifTrue: [ "wrapped" delta := delta + MaxMillisecondClockValue + 1 ]. BigMillisecondClock := BigMillisecondClock + delta. LastMillisecondClock := now.

here's some examples:

last = 1 now = 4 delta = (4 - 1) = 3 (normal)

last = MaxMillisecondClockValue now = 2 delta = (2 - MaxMillisecondClockValue) + MaxMillisecondClockValue + 1 = 3 (wrapped)

avi what was the reason not having it in?

Stef On 19 sept. 04, at 23:50, Avi Bryant wrote:

On Sep 19, 2004, at 11:34 PM, John Pierce wrote:

...

Hi all,

I am trying to make sure I am not missing something, but I really would like DateAndTime now to return the current date/time with millisecond clock precision. I know there has been a lot of discussions on this in the past with folks desiring nanosecond precision -- but how about just millisecond precision from the system clock.

Am I overlooking something or is this just not implemented on DateAndTime now?

The problem is that you don't know what the offset is between the millisecond clock value and the current time in seconds. The only way is to watch the millisecond clock and try to figure out what the value is when the second clock ticks over. I posted a changeset that does this calibration and gives DateAndTime now millisecond precision, but at the time the decision was not to harvest it. You may still find it useful, however:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-February/ 074400.html

Avi