thanks a lot! Friday we have an official sprint so I'm sure that this issue will be addressed.
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 > > > > > > > >
