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 <[hidden email]> wrote:

On 4 February 2013 16:48, Sven Van Caekenberghe <[hidden email]> wrote:
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 <[hidden email]> wrote:
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

On 05 Feb 2013, at 07:00, Denis Kudriashov <[hidden email]> wrote:

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.

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