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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] 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 >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Administrator
|
In reply to this post by Max Leske
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
Cheers,
Sean |
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 |
Administrator
|
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). I'm actually envisioning a simplification - don't change to local offset; or if we do, apply it after the date is calculated.
Cheers,
Sean |
In reply to this post by Sean P. DeNigris
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. > epochtest.1.cs (1K) Download Attachment |
Free forum by Nabble | Edit this page |