Bug in DateAndTime?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug in DateAndTime?

Max Leske
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
Reply | Threaded
Open this post in threaded view
|

Re: Bug in DateAndTime?

Stéphane Ducasse
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
Reply | Threaded
Open this post in threaded view
|

Re: Bug in DateAndTime?

Max Leske
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
Reply | Threaded
Open this post in threaded view
|

Re: Bug in DateAndTime?

Stéphane Ducasse

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
Reply | Threaded
Open this post in threaded view
|

Re: Bug in DateAndTime?

Max Leske
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
Reply | Threaded
Open this post in threaded view
|

Re: Bug in DateAndTime?

Sean P. DeNigris
Administrator
In reply to this post by Max Leske
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
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Bug in DateAndTime?

David T. Lewis
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


Reply | Threaded
Open this post in threaded view
|

Re: Bug in DateAndTime?

Sean P. DeNigris
Administrator
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.
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: Bug in DateAndTime?

NorbertHartl
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