[Pharo-project] Trying to understand DateAndTime
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. 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
On Apr 27, 2013, at 6:33 PM, Nicolas Cellier <nicolas.cellier.aka.nice@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
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.ducasse@free.fr>
On Apr 27, 2013, at 6:33 PM, Nicolas Cellier < nicolas.cellier.aka.nice@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
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.nice@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.ducasse@free.fr>
On Apr 27, 2013, at 6:33 PM, Nicolas Cellier < nicolas.cellier.aka.nice@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
Nicolas Cellier wrote
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.
I was a bit confused at first too. You have to click "Resolved" and then you get a whole other set of states, including "fix review needed". I've done it for this issue... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Trying-to-understand-DateAndTime-tp4683997p4684063.htm... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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.nice@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.ducasse@free.fr>
On Apr 27, 2013, at 6:33 PM, Nicolas Cellier <nicolas.cellier.aka.nice@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
On 28 April 2013 08:41, stephane ducasse <stephane.ducasse@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.nice@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.ducasse@free.fr>
On Apr 27, 2013, at 6:33 PM, Nicolas Cellier <nicolas.cellier.aka.nice@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.
Igor, do you mean everything related to millisecondClockValue (primitive 135)? That would be very good to get rid of this useless complexity! Of course it might cost some image freeze since used in Delay (I accidentally caused a few, but then narrowed my changes to something softer). 2013/4/28 Igor Stasenko <siguctua@gmail.com>
On 28 April 2013 08:41, stephane ducasse <stephane.ducasse@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.nice@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.ducasse@free.fr>
On Apr 27, 2013, at 6:33 PM, Nicolas Cellier <nicolas.cellier.aka.nice@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.
On 28 April 2013 16:19, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Igor, do you mean everything related to millisecondClockValue (primitive 135)? yes.
That would be very good to get rid of this useless complexity! Of course it might cost some image freeze since used in Delay (I accidentally caused a few, but then narrowed my changes to something softer).
yes.. another reason why i want to get rid of that complicated code which involves Delays.
2013/4/28 Igor Stasenko <siguctua@gmail.com>
On 28 April 2013 08:41, stephane ducasse <stephane.ducasse@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.nice@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.ducasse@free.fr>
On Apr 27, 2013, at 6:33 PM, Nicolas Cellier <nicolas.cellier.aka.nice@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.
-- Best regards, Igor Stasenko.
Igor could you review the changes of nicolas - I was planning to do it now but I'm dead so I will do it but with half of my mind. Because may be this is better to integrate his changes then do another pass friday. Stef On Apr 28, 2013, at 3:38 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 28 April 2013 08:41, stephane ducasse <stephane.ducasse@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.nice@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.ducasse@free.fr>
On Apr 27, 2013, at 6:33 PM, Nicolas Cellier <nicolas.cellier.aka.nice@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.
Nicolas Cellier wrote
What I find strange: - #hash uses the offset... Why ???
Maybe because of this: http://forum.world.st/true-hash-tp4621497p4624623.html which you fixed here: See http://forum.world.st/true-hash-tp4621497p4624706.html -- View this message in context: http://forum.world.st/Trying-to-understand-DateAndTime-tp4683997p4684123.htm... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Yes, this was valid when jdn, seconds and nanos where maintained in local time... 2013/4/28 Paul DeBruicker <pdebruic@gmail.com>
Nicolas Cellier wrote
What I find strange: - #hash uses the offset... Why ???
Maybe because of this: http://forum.world.st/true-hash-tp4621497p4624623.html
which you fixed here:
See http://forum.world.st/true-hash-tp4621497p4624706.html
-- View this message in context: http://forum.world.st/Trying-to-understand-DateAndTime-tp4683997p4684123.htm... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Nicolas I read all the slice and I like it (even if they are place where I do not get fully it :). I'm dead. So may be this is obvious but I do not understand the or: logic If the seconds is negative I do not understand what is happening. normalizeSecondsAndNanos (NanosInSecond <= nanos or: [ nanos < 0 ]) ifTrue: [ seconds := seconds + (nanos // NanosInSecond). nanos := nanos \\ NanosInSecond]. (SecondsInDay <= seconds or: [ seconds < 0 ]) ifTrue: [ julianDayNumber := julianDayNumber + (seconds // SecondsInDay). seconds := seconds \\ SecondsInDay]. Stef On Apr 28, 2013, at 7:03 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Yes, this was valid when jdn, seconds and nanos where maintained in local time...
2013/4/28 Paul DeBruicker <pdebruic@gmail.com> Nicolas Cellier wrote
What I find strange: - #hash uses the offset... Why ???
Maybe because of this: http://forum.world.st/true-hash-tp4621497p4624623.html
which you fixed here:
See http://forum.world.st/true-hash-tp4621497p4624706.html
-- View this message in context: http://forum.world.st/Trying-to-understand-DateAndTime-tp4683997p4684123.htm... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
\\ returns a positive remainder. example: -1 \\ 86400 -> 86399 -1 // 86400 -> -1 So the jdn is decremented and seconds are correctly normalized. 2013/4/28 stephane ducasse <stephane.ducasse@free.fr>
Nicolas
I read all the slice and I like it (even if they are place where I do not get fully it :). I'm dead. So may be this is obvious but I do not understand the or: logic If the seconds is negative I do not understand what is happening.
normalizeSecondsAndNanos (NanosInSecond <= nanos or: [ nanos < 0 ]) ifTrue: [ seconds := seconds + (nanos // NanosInSecond). nanos := nanos \\ NanosInSecond]. (SecondsInDay <= seconds or: [ seconds < 0 ]) ifTrue: [ julianDayNumber := julianDayNumber + (seconds // SecondsInDay). seconds := seconds \\ SecondsInDay].
Stef
On Apr 28, 2013, at 7:03 PM, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Yes, this was valid when jdn, seconds and nanos where maintained in local time...
2013/4/28 Paul DeBruicker <pdebruic@gmail.com>
Nicolas Cellier wrote
What I find strange: - #hash uses the offset... Why ???
Maybe because of this: http://forum.world.st/true-hash-tp4621497p4624623.html
which you fixed here:
See http://forum.world.st/true-hash-tp4621497p4624706.html
-- View this message in context: http://forum.world.st/Trying-to-understand-DateAndTime-tp4683997p4684123.htm... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Apr 28, 2013, at 11:19 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
\\ returns a positive remainder. example: -1 \\ 86400 -> 86399 -1 // 86400 -> -1
Yes I saw that and now I realized I understand it. But funnily I did not notice the difference between the use of // and \\
So the jdn is decremented and seconds are correctly normalized.
2013/4/28 stephane ducasse <stephane.ducasse@free.fr> Nicolas
I read all the slice and I like it (even if they are place where I do not get fully it :). I'm dead. So may be this is obvious but I do not understand the or: logic If the seconds is negative I do not understand what is happening.
normalizeSecondsAndNanos (NanosInSecond <= nanos or: [ nanos < 0 ]) ifTrue: [ seconds := seconds + (nanos // NanosInSecond). nanos := nanos \\ NanosInSecond]. (SecondsInDay <= seconds or: [ seconds < 0 ]) ifTrue: [ julianDayNumber := julianDayNumber + (seconds // SecondsInDay). seconds := seconds \\ SecondsInDay].
Stef
On Apr 28, 2013, at 7:03 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Yes, this was valid when jdn, seconds and nanos where maintained in local time...
2013/4/28 Paul DeBruicker <pdebruic@gmail.com> Nicolas Cellier wrote
What I find strange: - #hash uses the offset... Why ???
Maybe because of this: http://forum.world.st/true-hash-tp4621497p4624623.html
which you fixed here:
See http://forum.world.st/true-hash-tp4621497p4624706.html
-- View this message in context: http://forum.world.st/Trying-to-understand-DateAndTime-tp4683997p4684123.htm... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 29 April 2013 07:39, stephane ducasse <stephane.ducasse@free.fr> wrote:
On Apr 28, 2013, at 11:19 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
\\ returns a positive remainder. example: -1 \\ 86400 -> 86399 -1 // 86400 -> -1
Yes I saw that and now I realized I understand it. But funnily I did not notice the difference between the use of // and \\
i always confuse them.
So the jdn is decremented and seconds are correctly normalized.
2013/4/28 stephane ducasse <stephane.ducasse@free.fr>
Nicolas
I read all the slice and I like it (even if they are place where I do not get fully it :). I'm dead. So may be this is obvious but I do not understand the or: logic If the seconds is negative I do not understand what is happening.
normalizeSecondsAndNanos (NanosInSecond <= nanos or: [ nanos < 0 ]) ifTrue: [ seconds := seconds + (nanos // NanosInSecond). nanos := nanos \\ NanosInSecond]. (SecondsInDay <= seconds or: [ seconds < 0 ]) ifTrue: [ julianDayNumber := julianDayNumber + (seconds // SecondsInDay). seconds := seconds \\ SecondsInDay].
Stef
On Apr 28, 2013, at 7:03 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Yes, this was valid when jdn, seconds and nanos where maintained in local time...
2013/4/28 Paul DeBruicker <pdebruic@gmail.com>
Nicolas Cellier wrote
What I find strange: - #hash uses the offset... Why ???
Maybe because of this: http://forum.world.st/true-hash-tp4621497p4624623.html
which you fixed here:
See http://forum.world.st/true-hash-tp4621497p4624706.html
-- View this message in context: http://forum.world.st/Trying-to-understand-DateAndTime-tp4683997p4684123.htm... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko.
participants (5)
-
Igor Stasenko -
Nicolas Cellier -
Paul DeBruicker -
Sean P. DeNigris -
stephane ducasse