Anonymous | Login | 01-15-2021 18:45 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Issue History ] [ Print ] | ||||||||
ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||||
0000474 | [Squeak] Kernel | feature | always | 10-28-04 15:38 | 05-26-08 18:33 | ||||
Reporter | MarcusDenker | View Status | public | ||||||
Assigned To | KenCausey | ||||||||
Priority | normal | Resolution | fixed | ||||||
Status | closed | Product Version | 3.10 | ||||||
Summary | 0000474: [BUG][FIX] accurateDateAndTimeNow-brp | ||||||||
Description |
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. |
||||||||
Additional Information | |||||||||
Attached Files |
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
||||||||
|
![]() |
|||||||||||||||||||||
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
|
![]() |
|
(0000554 - 1062 - 1319 - 1368 - 1368 - 1368 - 1368) 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 - 238 - 291 - 291 - 291 - 291 - 291) 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 - 54 - 54 - 54 - 54 - 54 - 54) Keith_Hodges 10-12-06 15:27 |
Fix to #readFrom so that nanoSecond is read correctly. |
(0007667 - 195 - 220 - 220 - 220 - 220 - 220) 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 - 1787 - 1944 - 1944 - 1944 - 1944 - 1944) Keith_Hodges 10-13-06 08:07 edited on: 10-13-06 10:13 |
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 - 874 - 1012 - 1012 - 1012 - 1012 - 1012) Keith_Hodges 12-14-06 05:24 edited on: 05-23-08 22:52 |
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 - 122 - 122 - 122 - 122 - 122 - 122) 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 - 78 - 84 - 84 - 84 - 84 - 84) edgardec 07-21-07 09:26 |
This now is 7128Improve Date And Time.cs and was in updates for 3.10 Thanks ! |
(0011295 - 191 - 191 - 191 - 191 - 191 - 191) 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 - 69 - 69 - 69 - 69 - 69 - 69) edgardec 10-11-07 09:44 |
I do. When I do the update. Sorry I forget change state of bug report |
(0011375 - 247 - 295 - 295 - 295 - 295 - 295) Keith_Hodges 10-24-07 13:12 edited on: 10-24-07 14:16 |
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 - 316 - 438 - 438 - 438 - 438 - 438) 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 - 172 - 172 - 172 - 172 - 172 - 172) 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 - 15 - 15 - 15 - 15 - 15 - 15) KenCausey 05-26-08 18:33 |
Fixed in 3.10.1 |
Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
225 total queries executed. 81 unique queries executed. |