On 28 April 2013 08:41, stephane ducasse <stephane.duca...@free.fr> wrote: > thanks a lot! > Friday we have an official sprint so I'm sure that this issue will be > addressed. > yes. and i hope i will put my changes into the soup as well. (i did not published them, and some bits are unfinished).
> Stef > > 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 >>> > >>> > >>> >>> >> > > -- Best regards, Igor Stasenko.
