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
MarcusDenker  
KenCausey  
normal  
closed 3.10  
fixed  
none    
none 3.10  
0000474: [BUG][FIX] accurateDateAndTimeNow-brp
Subject: [BUG][FIX] accurateDateAndTimeNow-brp
Author: Brent Pinkney
Date Posted: 16 March 2004
Archive ID: 21110
Comments:
Avi,

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 class-readFrom.st [^] (2,103 bytes) 10-12-06 15:29
 DateAndTime class-readFrom.1.st [^] (2,049 bytes) 10-12-06 15:41
 DateAndTime3.st [^] (27,235 bytes) 10-13-06 09:53
 Time.st [^] (21,880 bytes) 10-13-06 09:54
 DateAndTimeTest-testReadFrom.st [^] (1,191 bytes) 12-14-06 05:13
 ClassClonerTestResource.st [^] (1,924 bytes) 12-14-06 05:15
 DateAndTimeClockTest.st [^] (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 class-milliSecondsSinceMidnight.st [^] (914 bytes) 10-24-07 14:13

Notes
(0000554)
MarcusDenker   
10-28-04 15:38   
Subject: [BUG][FIX] accurateDateAndTimeNow-brp ( [er] needs to be reviewed again )
Author: brent.pinkney@aircom.co.za
Date Posted: 4 October 2004
Archive ID: 24957
Comments:

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:
 
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.
(0007658)
Keith_Hodges   
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

produces

 2002-05-16T17:20:45.000000001+01:01

also how about a millisecondAccessor on DateAndTime
(0007659)
Keith_Hodges   
10-12-06 15:27   
Fix to #readFrom so that nanoSecond is read correctly.
(0007667)
andreas   
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.
(0007669)
Keith_Hodges   
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 DateAndTime3.st and Time.st 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.

enjoy

[ 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)

(0008710)
Keith_Hodges   
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.

Files
1. DateAndTimeTest-testReadFrom.st
2. ClassClonerTestResource.st - for safely testing class side behaviour
3. DateAndTimeClockTest.st
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: 'ClassClonerTestResource.st'.
Installer mantis bug: 474 fix: 'DateAndTimeClockTest.st'.
Installer mantis bug: 474 fix: 'DateAndTimeTest-testReadFrom.st'.
Installer mantis bug: 474 fix: 'DateAndTime class-milliSecondsSinceMidnight.st'.
"fix end"

(0010812)
Keith_Hodges   
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
(0010907)
edgardec   
07-21-07 09:26   
This now is 7128Improve Date And Time.cs and was in updates for 3.10
Thanks !
(0011295)
simon   
10-10-07 23:06   
Edgar, the files ClassClonerTestResource.st and DateAndTimeClockTest.st above provide five tests for DateAndTimeClock, would you mind harvesting these also ? Any tests for this seem valuable.
(0011299)
edgardec   
10-11-07 09:44   
I do. When I do the update. Sorry I forget change state of bug report
(0011375)
Keith_Hodges   
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)

(0011377)
edgardec   
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 ]

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