See https://pharo.fogbugz.com/default.asp?10425# and corresponding SLICE in
3.0 inbox
Note: I don't know what is the policy with the labels/states of these bug
tracker, and it rather bothers me, but the SLICE is ready for tests/reviews.
2013/4/27 Nicolas Cellier <nicolas.cellier.aka.n...@gmail.com>
> There is more:
>
> 1) hasEqualTicks: use julianDayNumber instead of julianDayNumberUTC
> 2) (Time dateAndTime now) interprets the (Time localSeconds) which are
> from the wrong primitive (seconds ellapsed since squeak epoch translated to
> local time) as seconds ellapsed since squeak Epoch (UTC time).
>
> We should really ban the old primitive 137 and only use the new one (240
> which works with UTC microseconds).
>
> I think Camillo did a good job, but he stopped cleaning too soon.
> Ah, young guys are so impatient to invent the future ;)
>
>
> 2013/4/27 stephane ducasse <stephane.duca...@free.fr>
>
>>
>> On Apr 27, 2013, at 6:33 PM, Nicolas Cellier <
>> nicolas.cellier.aka.n...@gmail.com> wrote:
>>
>> > Since DateAndTime comment is out of date (sic !) and current
>> implementation seems not free of bug, here is an effort to summarize and
>> understand the whole thing, let's call this a review.
>>
>> Thanks this is a great initiative!
>>
>>
>> > Please tell me where my interpretations are wrong.
>> >
>> > 1) The DateAndTime is stored internally as
>> > - a point in UTC time (julianDayNumber, seconds, nanos)
>> > - an offset from UTC (a Duration) denoting the local time zone
>> >
>> > 2) The ticks method returns the UTC part {julianDayNumber. seconds.
>> nanos}
>> >
>> > 3) DateAndTime print themselves in local time using the offset
>> >
>> > 4) other methods (with some exceptions) return the local dateAndTime
>> parts (year month day hours minutes seconds)
>> >
>> > Exceptions are:
>> > - secondsSinceMidnight (which should be renamed secondsSinceMidnightUTC
>> IMO, even if the method is classified private)
>> > - julianDayNumberUTC as the name tells
>> >
>> > So far so good (but secondsSinceMidnight which is error prone)
>> >
>> > What I find strange:
>> > - #hash uses the offset... Why ???
>> >
>> > d1 := DateAndTime now.
>> > d2 := d1 offset: d1 offset + 1 hours.
>> > {
>> > d1 = d2.
>> > d1 hash = d2 hash.
>> > }
>> > gives #(true false), a clue?
>> >
>> > - #< compares julianDayNumber (the UTC inst. var.) with otherDate
>> julianDayNumber (with otherDate local offset) which seems wrong, it should
>> better use julianDayNumberUTC or (normalized) ticks.
>> >
>> > - #= could be simplified and accelerated if using #hasEqualTicks: (if
>> the ticks are correctly normalized though which would be the case since
>> #ticks:offset: does, unfortunately #setJdn:seconds:nanos:offset: does not).
>> >
>> > Some senders of #setJdn:seconds:nanos:offset: don't normalize the
>> day/seconds/nanos, though it should be their responsibility (DateAndTime
>> todayAtMilliSeconds: xxx) (DateAndTime todayAtNanoSeconds: xxx), not
>> counting year:month:day:hour:minute:second:nanoSecond:offset: which does
>> not either (many senders...).
>> > Maybe we should better let the normalization responsibility to
>> #setJdn:seconds:nanos:offset:.
>> >
>> > It remain to analyze the conversion protocol (asYear etc...) which
>> seems to use the local time year, but I don't understand the whole Timespan
>> thing right now (why DateAndTime now asYear starts now, and not on january
>> 1st?).
>> >
>> > Nicolas
>> >
>> >
>>
>>
>>
>
