SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

Mantis - Squeak
Viewing Issue Advanced Details
474 Kernel feature always 10-28-04 15:38 05-26-08 18:33
closed 3.10  
none 3.10  
0000474: [BUG][FIX] accurateDateAndTimeNow-brp
Subject: [BUG][FIX] accurateDateAndTimeNow-brp
Author: Brent Pinkney
Date Posted: 16 March 2004
Archive ID: 21110

I have merged Avi's your accurateDateAndTimeNow-avi changeset (v2) with
the original Chronology code.

This now answers the correct time (sweet mercy) , but preserves the logic
so that

    (DateAndTime now) <= (DateAndTime now) is always false.

I took the liberty of renaming a few methods to be more consistent.

On my box: [ 100000 timesRepeat: [ DateAndTime now] ] timeToRun ==> 17265

This changeset passes all the relevant SUnit tests in the
'Kernel-Chronology-Tests' category.
related to 0004669closed  [ENH] TimeForSpeed 
related to 0006718new  TimeTest>>testGeneralInquiries fails 
related to 0007036closed KenCausey Issue fix for 0006805 "Time now return fraction not integer" in 3.10.1 
related to 0007357closed lewis DateAndTime class>>localOffset broken since Mantis 474 
 accurateDateAndTimeNow-brp.1.cs.gz [^] (1,027 bytes) 10-28-04 15:38
 DateAndTime [^] (2,103 bytes) 10-12-06 15:29
 DateAndTime [^] (2,049 bytes) 10-12-06 15:41 [^] (27,235 bytes) 10-13-06 09:53 [^] (21,880 bytes) 10-13-06 09:54 [^] (1,191 bytes) 12-14-06 05:13 [^] (1,924 bytes) 12-14-06 05:15 [^] (4,578 bytes) 12-14-06 05:16
 Improve Date And Time.1.cs [^] (9,047 bytes) 12-14-06 05:20
 Improve Date And Time.2.cs [^] (8,612 bytes) 12-14-06 05:22
 Improve Date And Time.3.cs [^] (8,746 bytes) 06-13-07 21:36
 Improve Date And Time.4.cs [^] (9,024 bytes) 06-13-07 22:09
 Improve Date And Time.5.cs [^] (9,016 bytes) 06-16-07 05:48
 Improve Date And Time.6.cs [^] (9,010 bytes) 06-16-07 05:51
 DateAndTime [^] (914 bytes) 10-24-07 14:13

10-28-04 15:38   
Subject: [BUG][FIX] accurateDateAndTimeNow-brp ( [er] needs to be reviewed again )
Date Posted: 4 October 2004
Archive ID: 24957

Needs to be reviewed with Ned's proposal:

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:
BigMillisecondClock is an arbitrary-precision integer
LastMillisecondClock is a SmallInteger, a copy of the millisecondClock
last time we looked at it
MaxMillisecondClockValue is the maximum value of the millisecond clock
on this
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.
10-12-06 14:50   
DateAndTime-readFrom: stream is not handling the nano/milliseconds field correctly

' 2002-05-16T17:20:45.1+01:01' asDateAndTime



also how about a millisecondAccessor on DateAndTime
10-12-06 15:27   
Fix to #readFrom so that nanoSecond is read correctly.
10-12-06 21:57   
[ 100000 timesRepeat: [ DateAndTime now] ] timeToRun ==> 17265

This can't possibly be correct by one or two orders of magnitude. "DateAndTime now" should be a *lot* faster than 6000 calls/sec.
10-13-06 08:07   
I made a variant which effectively uses the millisecond clock for the time, and the second clock for the date. I do this in anticipation of the day when the vm primitives give us useful milliseconds (or nanoseconds) since midnight. But this seems to work pretty well.

I also discovered that avoiding the use of Duration in the instanciation of DateAndTime improves performance by a factor of x3 on Brent's observation. Making an accessor to set the instance vars directly without normalizing (which I dont think is needed if you give it sensible values) boosts that to a factor of x4.

Then removing the semaphore and use of the class var LastTicks improves speed up to a pretty wizzy 90x the original.

Perhaps for those of us who dont care about this we could use this extra speed.
  (DateAndTime now) <= (DateAndTime now) is always true*

I have uploaded and which implement the above.
DateAndTime rightNow, is the fastest 'wizzy'
DateAndTime nowUnique, uses the semaphore approach.
DateAndTime now, calls rightNow, and if it isnt different to the last time it falls back onto nowUnique for the best of both worlds.

Note that if you time #now, you will get the results for #nowUnique which is not what you really want.

In class Time-#now, sets the nanoSeconds using #millisecondSinceMidnight in the time instance whereas before Time-#now only set the seconds.

NOTE: This is bleeding edge proof of concept. No testing has been done as yet, no assessment as been made as to what happens when the day rolls over, or when the millisecond clock rolls over.


[ 100000 timesRepeat: [ self rightNow. ] ] timeToRun. 220ms (result normalised to be comparible with the above since my machine is approx 2.6 times slower than brents)

12-14-06 05:24   
I am pleased to announce a testable/tested incarnation of the millisecond clock implementation. It is much faster too. This handles the clock rollover, and midnight rollovers.

If the clock is not used for a number of days and may have lost synchronisation then a sanity check is performed that will recalculate the offsets.

2. - for safely testing class side behaviour
4. Improve Date And Time.2.cs
"fix begin"
Installer mantis bug: 474 fix: 'Improve Date And Time.6.cs'.
"fix test"
Installer mantis bug: 474 fix: ''.
Installer mantis bug: 474 fix: ''.
Installer mantis bug: 474 fix: ''.
Installer mantis bug: 474 fix: 'DateAndTime'.
"fix end"

06-13-07 22:09   
Improve Date And Time.4.cs caches the LocalTimeZoneOffset value, since some chronology packages were slowing it down a lot
07-21-07 09:26   
This now is 7128Improve Date And Time.cs and was in updates for 3.10
Thanks !
10-10-07 23:06   
Edgar, the files and above provide five tests for DateAndTimeClock, would you mind harvesting these also ? Any tests for this seem valuable.
10-11-07 09:44   
I do. When I do the update. Sorry I forget change state of bug report
10-24-07 13:12   
The millisecond clock wraparound is incorrectly set at SmallInteger maxVal, it should be (so I am informed)

SmallInteger maxVal // 2.

Method effected #millisecondSinceMidnight

Adjusted version of this method is now uploaded. (for 7143)

10-24-07 13:54   
OK. I change status to feedback.
Keith I load the Improve Date And Time.6.cs and only see
DateAndTime >> localOffset
    "Answer the duration we are offset from UTC"

    ^ LocalOffset ifNil:[ LocalOffset := self localTimeZone offset ]

milliSecondsSinceMidnight as
As difference with 7158
It's correct ?
05-23-08 23:49   
I have harvested Keith's DateAndTime as update 7174. I hope that finalizes this issue. Please let me know ASAP if that is not the case.
05-26-08 18:33   
Fixed in 3.10.1