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.