[Pharo-project] Nanosecond-precision DateAndTime?
Hi, i am maybe completely ignorant, but can someone tell me where such precision is used? In order to achieve this (or well, get close to), a current implementation goes into very long circles to squeeze accuracy from underlying OS & primitives.. just take a look at this code and tell me what you think: secondsWhenClockTicks "waits for the moment when a new second begins" | lastSecond delay | delay := Delay forMilliseconds: 1. lastSecond := self primSecondsClock. [ lastSecond = self primSecondsClock ] whileTrue: [ delay wait ]. ^ lastSecond + 1 initializeOffsets | durationSinceEpoch secondsSinceMidnight nowSecs | LastTick := 0. nowSecs := self clock secondsWhenClockTicks. LastMilliSeconds := self millisecondClockValue. durationSinceEpoch := Duration days: SqueakEpoch hours: 0 minutes: 0 seconds: nowSecs. DaysSinceEpoch := durationSinceEpoch days. secondsSinceMidnight := (durationSinceEpoch - (Duration days: DaysSinceEpoch hours: 0 minutes: 0 seconds: 0)) asSeconds. MilliSecondOffset := secondsSinceMidnight * 1000 - LastMilliSeconds what amuses me is then the way how TimeStamp class dealing with it to actually throw away extra precision: TimeStamp >> current "called by #now" | ts ticks | ts := super now. ticks := ts ticks. ticks at: 3 put: 0. ts ticks: ticks offset: ts offset. ^ ts DateAndTime>>ticks "Private - answer an array with our instance variables. Assumed to be UTC " ^ Array with: julianDayNumber with: seconds with: nanos. if it is not obvious for someone, the right way to reset the nanoseconds field in timestamp is not sending a message to existing timestamp, say #resetNanoseconds, NO! you should call a private method, which answers you an Array and then you do "at:3 put: 0", and then pass it again to same object as two arguments. -- Best regards, Igor Stasenko.
The more, the interesting, consider: DateAndTime class>>now " [ 10000 timesRepeat: [ self now. ] ] timeToRun / 10000.0 . If calls to DateAndTime-c-#now are within a single millisecond the semaphore code to ensure that (self now <= self now) slows things down considerably by a factor of about 20. The actual speed of a single call to DateAndTime-now in milliseconds is demonstrated by the unguarded method below. [ 100000 timesRepeat: [ self todayAtMilliSeconds: (self milliSecondsSinceMidnight) ] ] timeToRun / 100000.0 . 0.00494 0.00481 0.00492 0.00495 " | nanoTicks msm | nanoTicks := (msm := self milliSecondsSinceMidnight) * 1000000. (LastTick < nanoTicks) ifTrue: [ LastTick := nanoTicks. ^ self todayAtMilliSeconds: msm]. LastTickSemaphore critical: [ LastTick := LastTick + 1. ^ self todayAtNanoSeconds: LastTick] okay, since we multiply value by 1000000 we get a nanosecond precision. Right? :) Most funny is DateAndTime class comment (see how it is coherent with TimeStamp implementation): ------------ I represent a point in UTC time as defined by ISO 8601. I have zero duration. My implementation uses three SmallIntegers and a Duration: jdn - julian day number. seconds - number of seconds since midnight. nanos - the number of nanoseconds since the second. offset - duration from UTC. The nanosecond attribute is almost always zero but it defined for full ISO compliance and is suitable for timestamping. -------------- so i really wonder if it worth having so much for so nothing? :) -- Best regards, Igor Stasenko.
Yes, I just can't understand all this code ;-) The nanoseconds seemed overly ambitious to me. That was one of the reasons I am using my own ZTimestamp (loadable from the Configuration browser), together with the confusion coming from timezones (they are not needed internally, only for representations). If you keep the julianDayNumber, you can fit millisecond precision in a small integer as milliSecondsSinceMidnight. 60 * 60 * 24 * 1000 < SmallInteger maxVal Ideally, there should be one Timestamp interface with multiple implementations of different precisions, mixed transparently. One should only pay the price (space or time) for extra features when they are really needed. On 04 Feb 2013, at 16:18, Igor Stasenko <siguctua@gmail.com> wrote:
Hi, i am maybe completely ignorant, but can someone tell me where such precision is used?
In order to achieve this (or well, get close to), a current implementation goes into very long circles to squeeze accuracy from underlying OS & primitives.. just take a look at this code and tell me what you think:
secondsWhenClockTicks
"waits for the moment when a new second begins"
| lastSecond delay |
delay := Delay forMilliseconds: 1. lastSecond := self primSecondsClock. [ lastSecond = self primSecondsClock ] whileTrue: [ delay wait ].
^ lastSecond + 1
initializeOffsets | durationSinceEpoch secondsSinceMidnight nowSecs | LastTick := 0. nowSecs := self clock secondsWhenClockTicks. LastMilliSeconds := self millisecondClockValue. durationSinceEpoch := Duration days: SqueakEpoch hours: 0 minutes: 0 seconds: nowSecs. DaysSinceEpoch := durationSinceEpoch days. secondsSinceMidnight := (durationSinceEpoch - (Duration days: DaysSinceEpoch hours: 0 minutes: 0 seconds: 0)) asSeconds. MilliSecondOffset := secondsSinceMidnight * 1000 - LastMilliSeconds
what amuses me is then the way how TimeStamp class dealing with it to actually throw away extra precision:
TimeStamp >> current "called by #now"
| ts ticks | ts := super now.
ticks := ts ticks. ticks at: 3 put: 0. ts ticks: ticks offset: ts offset.
^ ts
DateAndTime>>ticks "Private - answer an array with our instance variables. Assumed to be UTC "
^ Array with: julianDayNumber with: seconds with: nanos.
if it is not obvious for someone, the right way to reset the nanoseconds field in timestamp is not sending a message to existing timestamp, say #resetNanoseconds, NO! you should call a private method, which answers you an Array and then you do "at:3 put: 0", and then pass it again to same object as two arguments.
-- Best regards, Igor Stasenko.
On 4 February 2013 16:48, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Yes, I just can't understand all this code ;-)
The nanoseconds seemed overly ambitious to me.
That was one of the reasons I am using my own ZTimestamp (loadable from the Configuration browser), together with the confusion coming from timezones (they are not needed internally, only for representations).
If you keep the julianDayNumber, you can fit millisecond precision in a small integer as milliSecondsSinceMidnight.
60 * 60 * 24 * 1000 < SmallInteger maxVal
Ideally, there should be one Timestamp interface with multiple implementations of different precisions, mixed transparently. One should only pay the price (space or time) for extra features when they are really needed.
i am not against having highly precise storage format (which would allow storing at arbitrary precision).. what i don't understand is why having so much logic in order to emulate such precision: to my opinion, if OS/VM don't provides such precision, so be it.. use what is given, because doing so "neat" hacks with millisecond clock is just waste of code as to me, because it is really belongs to primitive (so you don't have chance to be interrupted, nor you need to wait till "new second" will happen :) ). -- Best regards, Igor Stasenko.
On 4 February 2013 16:56, Igor Stasenko <siguctua@gmail.com> wrote:
On 4 February 2013 16:48, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Yes, I just can't understand all this code ;-)
The nanoseconds seemed overly ambitious to me.
That was one of the reasons I am using my own ZTimestamp (loadable from the Configuration browser), together with the confusion coming from timezones (they are not needed internally, only for representations).
If you keep the julianDayNumber, you can fit millisecond precision in a small integer as milliSecondsSinceMidnight.
60 * 60 * 24 * 1000 < SmallInteger maxVal
Ideally, there should be one Timestamp interface with multiple implementations of different precisions, mixed transparently. One should only pay the price (space or time) for extra features when they are really needed.
i am not against having highly precise storage format (which would allow storing at arbitrary precision).. what i don't understand is why having so much logic in order to emulate such precision: to my opinion, if OS/VM don't provides such precision, so be it.. use what is given, because doing so "neat" hacks with millisecond clock is just waste of code as to me, because it is really belongs to primitive (so you don't have chance to be interrupted, nor you need to wait till "new second" will happen :) ).
clarification: i meant, related to system time, like DateAndTime>>now , or TimeStamp>>now.. those two is by their nature is system-dependent.. and so, if underlying system does not supports higher than 1 ***second precision, there is no way how you will get it. For synthesizing dates and stamps (like reading from file) .. it is another story (the logic in the methods i presented is related only to system *current* time). -- Best regards, Igor Stasenko.
Hello 2013/2/4 Igor Stasenko <siguctua@gmail.com>
On 4 February 2013 16:56, Igor Stasenko <siguctua@gmail.com> wrote:
On 4 February 2013 16:48, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Yes, I just can't understand all this code ;-)
The nanoseconds seemed overly ambitious to me.
That was one of the reasons I am using my own ZTimestamp (loadable from the Configuration browser), together with the confusion coming from timezones (they are not needed internally, only for representations).
If you keep the julianDayNumber, you can fit millisecond precision in a small integer as milliSecondsSinceMidnight.
60 * 60 * 24 * 1000 < SmallInteger maxVal
Ideally, there should be one Timestamp interface with multiple implementations of different precisions, mixed transparently. One should only pay the price (space or time) for extra features when they are really needed.
i am not against having highly precise storage format (which would allow storing at arbitrary precision).. what i don't understand is why having so much logic in order to emulate such precision: to my opinion, if OS/VM don't provides such precision, so be it.. use what is given, because doing so "neat" hacks with millisecond clock is just waste of code as to me, because it is really belongs to primitive (so you don't have chance to be interrupted, nor you need to wait till "new second" will happen :) ).
clarification: i meant, related to system time, like DateAndTime>>now , or TimeStamp>>now..
those two is by their nature is system-dependent.. and so, if underlying system does not supports higher than 1 ***second precision, there is no way how you will get it.
A bit offtopic maybe but could you explain (or somebody) difference between DateAndTime and TimeStamp? When I need date and time object I always start to think what class I should use.
For synthesizing dates and stamps (like reading from file) .. it is another story (the logic in the methods i presented is related only to system *current* time).
-- Best regards, Igor Stasenko.
On 05 Feb 2013, at 07:00, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hello
2013/2/4 Igor Stasenko <siguctua@gmail.com> On 4 February 2013 16:56, Igor Stasenko <siguctua@gmail.com> wrote:
On 4 February 2013 16:48, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Yes, I just can't understand all this code ;-)
The nanoseconds seemed overly ambitious to me.
That was one of the reasons I am using my own ZTimestamp (loadable from the Configuration browser), together with the confusion coming from timezones (they are not needed internally, only for representations).
If you keep the julianDayNumber, you can fit millisecond precision in a small integer as milliSecondsSinceMidnight.
60 * 60 * 24 * 1000 < SmallInteger maxVal
Ideally, there should be one Timestamp interface with multiple implementations of different precisions, mixed transparently. One should only pay the price (space or time) for extra features when they are really needed.
i am not against having highly precise storage format (which would allow storing at arbitrary precision).. what i don't understand is why having so much logic in order to emulate such precision: to my opinion, if OS/VM don't provides such precision, so be it.. use what is given, because doing so "neat" hacks with millisecond clock is just waste of code as to me, because it is really belongs to primitive (so you don't have chance to be interrupted, nor you need to wait till "new second" will happen :) ).
clarification: i meant, related to system time, like DateAndTime>>now , or TimeStamp>>now..
those two is by their nature is system-dependent.. and so, if underlying system does not supports higher than 1 ***second precision, there is no way how you will get it.
A bit offtopic maybe but could you explain (or somebody) difference between DateAndTime and TimeStamp? When I need date and time object I always start to think what class I should use.
There is basically no difference, the only difference is in their external representation. DateAndTime now is more portable, and has a more technically correct ISO representation.
For synthesizing dates and stamps (like reading from file) .. it is another story (the logic in the methods i presented is related only to system *current* time).
-- Best regards, Igor Stasenko.
A bit offtopic maybe but could you explain (or somebody) difference between DateAndTime and TimeStamp? When I need date and time object I always start to think what class I should use.
TimeStamp is the rest of an old design because DateAndTime should just be able to print itself correctly. stef
participants (4)
-
Denis Kudriashov -
Igor Stasenko -
Stéphane Ducasse -
Sven Van Caekenberghe