[Pharo-project] Bug in DateAndTime?
Hi. Evaluating: DateAndTime now asUnixTime and then creating a DateAndTime object from the result: DateAndTime fromUnixTime: <seconds> does not yield an equivalent object. As far as I can tell, this is because the unix epoch is hard coded in two places: DateAndTime class>>unixEpoch "Answer a DateAndTime representing the Unix epoch (1 January 1970, midnight UTC)" ^ self basicNew ticks: #(2440588 0 0) offset: Duration zero; yourself. DateAndTime>>fromUnixTime: anInteger ^ self fromSeconds: anInteger + 2177452800 "unix epoch constant" So in the end I get a difference of 7200 seconds. I'll gladly open up a bug but can someone please confirm that this is actually a bug and that I didn't miss something? Cheers, Max
Dear Max Right now I do not know. which version are you using? Stef
Hi.
Evaluating:
DateAndTime now asUnixTime
and then creating a DateAndTime object from the result:
DateAndTime fromUnixTime: <seconds>
does not yield an equivalent object. As far as I can tell, this is because the unix epoch is hard coded in two places:
DateAndTime class>>unixEpoch "Answer a DateAndTime representing the Unix epoch (1 January 1970, midnight UTC)" ^ self basicNew ticks: #(2440588 0 0) offset: Duration zero; yourself.
DateAndTime>>fromUnixTime: anInteger ^ self fromSeconds: anInteger + 2177452800 "unix epoch constant"
So in the end I get a difference of 7200 seconds.
I'll gladly open up a bug but can someone please confirm that this is actually a bug and that I didn't miss something?
Cheers, Max _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Stef Me and Lukas just resolved the issue. It's not really a bug (although having two hard coded epochs seems a bit silly to me); the problem was in my code and the offset is time zone related. This means: my problem is solved and no bug report needs to be opened. Maybe at some point somone might consider a refactoring though... :) Thanks, Max On 19.07.2010, at 13:07, Stéphane Ducasse wrote:
Dear Max
Right now I do not know.
which version are you using?
Stef
Hi.
Evaluating:
DateAndTime now asUnixTime
and then creating a DateAndTime object from the result:
DateAndTime fromUnixTime: <seconds>
does not yield an equivalent object. As far as I can tell, this is because the unix epoch is hard coded in two places:
DateAndTime class>>unixEpoch "Answer a DateAndTime representing the Unix epoch (1 January 1970, midnight UTC)" ^ self basicNew ticks: #(2440588 0 0) offset: Duration zero; yourself.
DateAndTime>>fromUnixTime: anInteger ^ self fromSeconds: anInteger + 2177452800 "unix epoch constant"
So in the end I get a difference of 7200 seconds.
I'll gladly open up a bug but can someone please confirm that this is actually a bug and that I didn't miss something?
Cheers, Max _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Jul 19, 2010, at 2:19 PM, Max Leske wrote:
Hi Stef
Me and Lukas just resolved the issue. It's not really a bug (although having two hard coded epochs seems a bit silly to me); the problem was in my code and the offset is time zone related. This means: my problem is solved and no bug report needs to be opened. Maybe at some point somone might consider a refactoring though... :)
sure can you propose something and check it with lukas. We value better code!!!! Stef
Thanks, Max
On 19.07.2010, at 13:07, Stéphane Ducasse wrote:
Dear Max
Right now I do not know.
which version are you using?
Stef
Hi.
Evaluating:
DateAndTime now asUnixTime
and then creating a DateAndTime object from the result:
DateAndTime fromUnixTime: <seconds>
does not yield an equivalent object. As far as I can tell, this is because the unix epoch is hard coded in two places:
DateAndTime class>>unixEpoch "Answer a DateAndTime representing the Unix epoch (1 January 1970, midnight UTC)" ^ self basicNew ticks: #(2440588 0 0) offset: Duration zero; yourself.
DateAndTime>>fromUnixTime: anInteger ^ self fromSeconds: anInteger + 2177452800 "unix epoch constant"
So in the end I get a difference of 7200 seconds.
I'll gladly open up a bug but can someone please confirm that this is actually a bug and that I didn't miss something?
Cheers, Max _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Might be a few days but I'll try. Max On 19.07.2010, at 14:31, Stéphane Ducasse wrote:
On Jul 19, 2010, at 2:19 PM, Max Leske wrote:
Hi Stef
Me and Lukas just resolved the issue. It's not really a bug (although having two hard coded epochs seems a bit silly to me); the problem was in my code and the offset is time zone related. This means: my problem is solved and no bug report needs to be opened. Maybe at some point somone might consider a refactoring though... :)
sure can you propose something and check it with lukas. We value better code!!!!
Stef
Thanks, Max
On 19.07.2010, at 13:07, Stéphane Ducasse wrote:
Dear Max
Right now I do not know.
which version are you using?
Stef
Hi.
Evaluating:
DateAndTime now asUnixTime
and then creating a DateAndTime object from the result:
DateAndTime fromUnixTime: <seconds>
does not yield an equivalent object. As far as I can tell, this is because the unix epoch is hard coded in two places:
DateAndTime class>>unixEpoch "Answer a DateAndTime representing the Unix epoch (1 January 1970, midnight UTC)" ^ self basicNew ticks: #(2440588 0 0) offset: Duration zero; yourself.
DateAndTime>>fromUnixTime: anInteger ^ self fromSeconds: anInteger + 2177452800 "unix epoch constant"
So in the end I get a difference of 7200 seconds.
I'll gladly open up a bug but can someone please confirm that this is actually a bug and that I didn't miss something?
Cheers, Max _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Max Leske wrote
DateAndTime fromUnixTime: <seconds>
DateAndTime>>fromUnixTime: anInteger ^ self fromSeconds: anInteger + 2177452800 "unix epoch constant"
This seems like a bug to me. Wikipedia defines unix epoch time as "the number of seconds elapsed since midnight Coordinated Universal Time (UTC)..." However, #fromSeconds: takes the resulting time and simply tacks on the local offset. For example, it makes 12:02pm+0hrs into 12:02pm-4hrs (for NY). I scraped a unix time from an html page, and put it into Pharo. The unix time was based (correctly as defined above) on UTC, so in this case, it should have done: 12:02pm+0hrs -> 8:02am-4hrs instead of 12:02pm+0hrs -> 12:02pm-4hrs To get the correct result now, one has to jump through hoops like: DateAndTime fromUnixTime: (1332807176 + DateAndTime localOffset asSeconds). or ((DateAndTime fromUnixTime: 1332807176) offset: Duration zero) asLocal Does all this sound right? If so, I'll create an issue for it... Sean -- View this message in context: http://forum.world.st/Bug-in-DateAndTime-tp2293749p4507847.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Mon, Mar 26, 2012 at 08:17:17PM -0700, Sean P. DeNigris wrote:
Max Leske wrote
DateAndTime fromUnixTime: <seconds>
DateAndTime>>fromUnixTime: anInteger ^ self fromSeconds: anInteger + 2177452800 "unix epoch constant"
This seems like a bug to me. Wikipedia defines unix epoch time as "the number of seconds elapsed since midnight Coordinated Universal Time (UTC)..."
However, #fromSeconds: takes the resulting time and simply tacks on the local offset. For example, it makes 12:02pm+0hrs into 12:02pm-4hrs (for NY).
I scraped a unix time from an html page, and put it into Pharo. The unix time was based (correctly as defined above) on UTC, so in this case, it should have done: 12:02pm+0hrs -> 8:02am-4hrs instead of 12:02pm+0hrs -> 12:02pm-4hrs
To get the correct result now, one has to jump through hoops like: DateAndTime fromUnixTime: (1332807176 + DateAndTime localOffset asSeconds). or ((DateAndTime fromUnixTime: 1332807176) offset: Duration zero) asLocal
Does all this sound right? If so, I'll create an issue for it...
(cc to squeak-dev) The Squeak Chronology system has limited ability to deal with time zone offsets, which are not static offsets but vary as a function of time for any given time zone. The problem you are seeing here is not a single bug, it is one of many symptoms of this limited implementation. See TimeZoneDatabase on SqueakSource for one way to address this: http://wiki.squeak.org/squeak/1076 Chronos is another implementation: http://chronos-st.org/ The current implementation with fixed offsets is simple and fast, so you may consider the limited implementation to be either a bug or a feature depending on your use case ;) Dave
David T. Lewis wrote
you may consider the limited implementation to be either a bug or a feature depending on your use case ;)
Ha ha, maybe that could be said of any code ;-) But, in this case, when one has a Unix time, that already means something in the outside world. We're reusing the label to mean something else - a recipe for disaster (or at least confusion). David T. Lewis wrote
The current implementation... is simple and fast,
I'm actually envisioning a simplification - don't change to local offset; or if we do, apply it after the date is calculated. -- View this message in context: http://forum.world.st/Bug-in-DateAndTime-tp2293749p4508750.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Sean, I discovered that 2 month ago and did not make a submission. I fixed it by not relying on julianDay when using epoch. It is DateAndTime class>>epoch "Answer a DateAndTime representing the Squeak epoch: 1 January 1901 in UTC timezone" ^ self basicNew ticks: SqueakEpoch days ticks offset: Duration zero; yourself I wanted to submit the fix but then a few tests fail with this change. One test I identified that coded the wrong assumption about duration into the test. But then I didn't find enough time to fix the rest. I attach what I've got so far. It is the change and a test that tests the shift. Sorry for not submitting that earlier. It is a fix for 1.3 norbert Am 27.03.2012 um 05:17 schrieb Sean P. DeNigris:
Max Leske wrote
DateAndTime fromUnixTime: <seconds>
DateAndTime>>fromUnixTime: anInteger ^ self fromSeconds: anInteger + 2177452800 "unix epoch constant"
This seems like a bug to me. Wikipedia defines unix epoch time as "the number of seconds elapsed since midnight Coordinated Universal Time (UTC)..."
However, #fromSeconds: takes the resulting time and simply tacks on the local offset. For example, it makes 12:02pm+0hrs into 12:02pm-4hrs (for NY).
I scraped a unix time from an html page, and put it into Pharo. The unix time was based (correctly as defined above) on UTC, so in this case, it should have done: 12:02pm+0hrs -> 8:02am-4hrs instead of 12:02pm+0hrs -> 12:02pm-4hrs
To get the correct result now, one has to jump through hoops like: DateAndTime fromUnixTime: (1332807176 + DateAndTime localOffset asSeconds). or ((DateAndTime fromUnixTime: 1332807176) offset: Duration zero) asLocal
Does all this sound right? If so, I'll create an issue for it...
Sean
-- View this message in context: http://forum.world.st/Bug-in-DateAndTime-tp2293749p4507847.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
participants (5)
-
David T. Lewis -
Max Leske -
Norbert Hartl -
Sean P. DeNigris -
Stéphane Ducasse