Smalltalk › Pharo › Pharo Smalltalk Developers

DateAndTime class>>midnight

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

11 messages Options

Max Leske

DateAndTime class>>midnight

Possible bug in 2.0 which messes with equality checks:

"DateAndTime midnight" will answer a DateAndTime with seconds set to the UTC seconds. In my case (UTC +1) that's -3600 seconds. I'm pretty sure that seconds should be 0.
This messes up equality checks for Date because Date class>>current uses #midnight.

Please confirm and I'll open a bug report.

Cheers,
Max

Camillo Bruni-3

Re: DateAndTime class>>midnight

midnight should be local time and DateAndTime work internally with UTC time only

so yes this is wrong :), #seconds should be 0 and only the timezone has "special" values.

On 2012-12-29, at 18:51, Max Leske <[hidden email]> wrote:

> Possible bug in 2.0 which messes with equality checks:
>
> "DateAndTime midnight" will answer a DateAndTime with seconds set to the UTC seconds. In my case (UTC +1) that's -3600 seconds. I'm pretty sure that seconds should be 0.
> This messes up equality checks for Date because Date class>>current uses #midnight.
>
> Please confirm and I'll open a bug report.
>
> Cheers,
> Max

Camillo Bruni-3

Re: DateAndTime class>>midnight

ah no wait :) this is fine :) it's midnight from your local time-zone.

hence the seconds change in UTC ;)

#seconds + #offset = 0

so this is fine ;)

On 2012-12-29, at 19:54, Camillo Bruni <[hidden email]> wrote:

> midnight should be local time and DateAndTime work internally with UTC time only
>
> so yes this is wrong :), #seconds should be 0 and only the timezone has "special" values.
>
> On 2012-12-29, at 18:51, Max Leske <[hidden email]> wrote:
>
>> Possible bug in 2.0 which messes with equality checks:
>>
>> "DateAndTime midnight" will answer a DateAndTime with seconds set to the UTC seconds. In my case (UTC +1) that's -3600 seconds. I'm pretty sure that seconds should be 0.
>> This messes up equality checks for Date because Date class>>current uses #midnight.
>>
>> Please confirm and I'll open a bug report.
>>
>> Cheers,
>> Max
>

Max Leske

Re: DateAndTime class>>midnight

Hm. Ok. It still looks really weird. The comment in #midnight states that it answers midnight in the local time zone. That comment is now wrong, isn't it? #midnight now answers midnight UTC (??).

In any case, I see two problems:
1. as already said, comparison operations on Date are broken (and on DateAndTime)
2. "midnight" is no longer the same as "midnight". Consider the following example:

now := DateAndTime now.
midnight := now - now hours hours - now minutes minutes - now seconds seconds - now nanoSecond nanoSecond.
midnight = DateAndTime midnight "---> true"

Interestingly, this evaluates to true in both 1.4 and 2.0. BUT: in 2.0 the objects have different julian day numbers and different seconds. I would hardly call those objects equal…

I'm also pretty unhappy with the API changes to DateAndTime. For instance, "DateAndTime now seconds" is not the same as "DateAndTime now instVarNamed: 'seconds'". That's really frustrating when debugging those objects.

Sorry Cami, I know that's your work :)

On 30.12.2012, at 00:01, Camillo Bruni <[hidden email]> wrote:

> ah no wait :) this is fine :) it's midnight from your local time-zone.
>
> hence the seconds change in UTC ;)
>
> #seconds + #offset = 0
>
> so this is fine ;)
>
> On 2012-12-29, at 19:54, Camillo Bruni <[hidden email]> wrote:
>
>> midnight should be local time and DateAndTime work internally with UTC time only
>>
>> so yes this is wrong :), #seconds should be 0 and only the timezone has "special" values.
>>
>> On 2012-12-29, at 18:51, Max Leske <[hidden email]> wrote:
>>
>>> Possible bug in 2.0 which messes with equality checks:
>>>
>>> "DateAndTime midnight" will answer a DateAndTime with seconds set to the UTC seconds. In my case (UTC +1) that's -3600 seconds. I'm pretty sure that seconds should be 0.
>>> This messes up equality checks for Date because Date class>>current uses #midnight.
>>>
>>> Please confirm and I'll open a bug report.
>>>
>>> Cheers,
>>> Max
>>
>
>

Sven Van Caekenberghe-2

Re: DateAndTime class>>midnight

Max,

On 30 Dec 2012, at 09:42, Max Leske <[hidden email]> wrote:

> Hm. Ok. It still looks really weird. The comment in #midnight states that it answers midnight in the local time zone. That comment is now wrong, isn't it? #midnight now answers midnight UTC (??).
>
> In any case, I see two problems:
> 1. as already said, comparison operations on Date are broken (and on DateAndTime)
> 2. "midnight" is no longer the same as "midnight". Consider the following example:
>
> now := DateAndTime now.
> midnight := now - now hours hours - now minutes minutes - now seconds seconds - now nanoSecond nanoSecond.
> midnight = DateAndTime midnight "---> true"
>
> Interestingly, this evaluates to true in both 1.4 and 2.0. BUT: in 2.0 the objects have different julian day numbers and different seconds. I would hardly call those objects equal…
>
> I'm also pretty unhappy with the API changes to DateAndTime. For instance, "DateAndTime now seconds" is not the same as "DateAndTime now instVarNamed: 'seconds'". That's really frustrating when debugging those objects.
>
> Sorry Cami, I know that's your work :)

This is not a comment on the problem itself, but on your arguments.
An object is how it behaves, not what its instance variables hold.
If two objects are equal for #= and behave the same, then it does not matter what's inside.

Unless you really need timezones (why since they are mostly a representation aspect ?), you could have a look at ZTimestamp in http://mc.stfx.eu/Neo which is much simpler.

Sven

> On 30.12.2012, at 00:01, Camillo Bruni <[hidden email]> wrote:
>
>> ah no wait :) this is fine :) it's midnight from your local time-zone.
>>
>> hence the seconds change in UTC ;)
>>
>> #seconds + #offset = 0
>>
>> so this is fine ;)
>>
>> On 2012-12-29, at 19:54, Camillo Bruni <[hidden email]> wrote:
>>
>>> midnight should be local time and DateAndTime work internally with UTC time only
>>>
>>> so yes this is wrong :), #seconds should be 0 and only the timezone has "special" values.
>>>
>>> On 2012-12-29, at 18:51, Max Leske <[hidden email]> wrote:
>>>
>>>> Possible bug in 2.0 which messes with equality checks:
>>>>
>>>> "DateAndTime midnight" will answer a DateAndTime with seconds set to the UTC seconds. In my case (UTC +1) that's -3600 seconds. I'm pretty sure that seconds should be 0.
>>>> This messes up equality checks for Date because Date class>>current uses #midnight.
>>>>
>>>> Please confirm and I'll open a bug report.
>>>>
>>>> Cheers,
>>>> Max
>>>
>>
>>
>
>

Max Leske

Re: DateAndTime class>>midnight

On 30.12.2012, at 10:50, Sven Van Caekenberghe <[hidden email]> wrote:

> Max,
>
> On 30 Dec 2012, at 09:42, Max Leske <[hidden email]> wrote:
>
>> Hm. Ok. It still looks really weird. The comment in #midnight states that it answers midnight in the local time zone. That comment is now wrong, isn't it? #midnight now answers midnight UTC (??).
>>
>> In any case, I see two problems:
>> 1. as already said, comparison operations on Date are broken (and on DateAndTime)
>> 2. "midnight" is no longer the same as "midnight". Consider the following example:
>>
>> now := DateAndTime now.
>> midnight := now - now hours hours - now minutes minutes - now seconds seconds - now nanoSecond nanoSecond.
>> midnight = DateAndTime midnight "---> true"
>>
>> Interestingly, this evaluates to true in both 1.4 and 2.0. BUT: in 2.0 the objects have different julian day numbers and different seconds. I would hardly call those objects equal…
>>
>> I'm also pretty unhappy with the API changes to DateAndTime. For instance, "DateAndTime now seconds" is not the same as "DateAndTime now instVarNamed: 'seconds'". That's really frustrating when debugging those objects.
>>
>> Sorry Cami, I know that's your work :)
>
> This is not a comment on the problem itself, but on your arguments.
> An object is how it behaves, not what its instance variables hold.
> If two objects are equal for #= and behave the same, then it does not matter what's inside.
>

You're right of course. But that doesn't mean that messages should obfuscate the internals of an object. All I meant to say is that I believe in simple objects and simple relationships between objects and I don't think that DateAndTime is simple enough (just to clarify: I don't think I could do it any better :) I know that dates and times can be a can of worms).

> Unless you really need timezones (why since they are mostly a representation aspect ?), you could have a look at ZTimestamp in http://mc.stfx.eu/Neo which is much simpler.

Thanks for the pointer. No, I don't need time zones. I stumbled upon this "problem" (or not…) while debugging a date comparison issue that suddenly cropped up (beause of #midnight).

>
> Sven
>
>> On 30.12.2012, at 00:01, Camillo Bruni <[hidden email]> wrote:
>>
>>> ah no wait :) this is fine :) it's midnight from your local time-zone.
>>>
>>> hence the seconds change in UTC ;)
>>>
>>> #seconds + #offset = 0
>>>
>>> so this is fine ;)
>>>
>>> On 2012-12-29, at 19:54, Camillo Bruni <[hidden email]> wrote:
>>>
>>>> midnight should be local time and DateAndTime work internally with UTC time only
>>>>
>>>> so yes this is wrong :), #seconds should be 0 and only the timezone has "special" values.
>>>>
>>>> On 2012-12-29, at 18:51, Max Leske <[hidden email]> wrote:
>>>>
>>>>> Possible bug in 2.0 which messes with equality checks:
>>>>>
>>>>> "DateAndTime midnight" will answer a DateAndTime with seconds set to the UTC seconds. In my case (UTC +1) that's -3600 seconds. I'm pretty sure that seconds should be 0.
>>>>> This messes up equality checks for Date because Date class>>current uses #midnight.
>>>>>
>>>>> Please confirm and I'll open a bug report.
>>>>>
>>>>> Cheers,
>>>>> Max
>>>>
>>>
>>>
>>
>>
>
>

Camillo Bruni-3

Re: DateAndTime class>>midnight

In reply to this post by Max Leske

On 2012-12-30, at 05:42, Max Leske <[hidden email]> wrote:

thats a fully correct observation but a wrong conclusion :)

old: internal, external representation and 0-point were local time
new: internal representation and 0-point are in UTC, external representation are in local time

for comparisons we now simply compare the internal representation in UTC,
which makes everything way simpler.

> I'm also pretty unhappy with the API changes to DateAndTime. For instance, "DateAndTime now seconds" is not the same as "DateAndTime now instVarNamed: 'seconds'". That's really frustrating when debugging those objects.
>
> Sorry Cami, I know that's your work :)

haha well consider it as one of these nasty things in pharo you got used to.
DateAndTime was sincerely broken in pre 2.0 images.
Moving an image between a timezone yielded wrong DateAndTimes (which btw happens
twice per year when switching from/to daylight saving time). The only way
to solve the mess is to have a fixed reference point, in this case UTC.

- internally everything is in UTC
- externally everything is in local time

believe me that was harder than you think ;) we did a nasty hackathon of 8hours
to get "everything" straight.

That said, it might be confusing compared to pre 2.0 images but it makes definitely
more sense. Hence I can only conclude that the code you use from pre 2.0 era is wrong :D

Stéphane Ducasse

Re: DateAndTime class>>midnight

camillo

is your explanation in the class comment?
Because if you say that this is nasty….
It is worth documenting it :)

Stef

On Dec 30, 2012, at 2:00 PM, Camillo Bruni wrote:

>
> On 2012-12-30, at 05:42, Max Leske <[hidden email]> wrote:
>
>> Hm. Ok. It still looks really weird. The comment in #midnight states that it answers midnight in the local time zone. That comment is now wrong, isn't it? #midnight now answers midnight UTC (??).
>>
>> In any case, I see two problems:
>> 1. as already said, comparison operations on Date are broken (and on DateAndTime)
>> 2. "midnight" is no longer the same as "midnight". Consider the following example:
>>
>> now := DateAndTime now.
>> midnight := now - now hours hours - now minutes minutes - now seconds seconds - now nanoSecond nanoSecond.
>> midnight = DateAndTime midnight "---> true"
>>
>> Interestingly, this evaluates to true in both 1.4 and 2.0. BUT: in 2.0 the objects have different julian day numbers and different seconds. I would hardly call those objects equal…
>
> thats a fully correct observation but a wrong conclusion :)
>
> old: internal, external representation and 0-point were local time
> new: internal representation and 0-point are in UTC, external representation are in local time
>
> for comparisons we now simply compare the internal representation in UTC,
> which makes everything way simpler.
>
>> I'm also pretty unhappy with the API changes to DateAndTime. For instance, "DateAndTime now seconds" is not the same as "DateAndTime now instVarNamed: 'seconds'". That's really frustrating when debugging those objects.
>>
>> Sorry Cami, I know that's your work :)
>
>
> haha well consider it as one of these nasty things in pharo you got used to.
> DateAndTime was sincerely broken in pre 2.0 images.
> Moving an image between a timezone yielded wrong DateAndTimes (which btw happens
> twice per year when switching from/to daylight saving time). The only way
> to solve the mess is to have a fixed reference point, in this case UTC.
>
> - internally everything is in UTC
> - externally everything is in local time
>
> believe me that was harder than you think ;) we did a nasty hackathon of 8hours
> to get "everything" straight.
>
> That said, it might be confusing compared to pre 2.0 images but it makes definitely
> more sense. Hence I can only conclude that the code you use from pre 2.0 era is wrong :D

Camillo Bruni-3

Re: DateAndTime class>>midnight

On 2012-12-30, at 10:26, Stéphane Ducasse <[hidden email]> wrote:

> camillo
>
> is your explanation in the class comment?
> Because if you say that this is nasty….
> It is worth documenting it :)

It says that DateAndTime uses UTC time so technically all the information is there.
But the comment could indeed require some more love ;)

Max Leske

Re: DateAndTime class>>midnight

In reply to this post by Camillo Bruni-3

Ok, thanks for the explanation. I'll go back to the drawing board. And once I've figured it out I might even come up with a helpful class comment :)

On 30.12.2012, at 14:00, Camillo Bruni <[hidden email]> wrote:

Stéphane Ducasse

Re: DateAndTime class>>midnight

On Dec 30, 2012, at 3:02 PM, Max Leske wrote:

> Ok, thanks for the explanation. I'll go back to the drawing board. And once I've figured it out I might even come up with a helpful class comment :)

oh yes!!!!
Please

> On 30.12.2012, at 14:00, Camillo Bruni <[hidden email]> wrote:
>
>>
>> On 2012-12-30, at 05:42, Max Leske <[hidden email]> wrote:
>>
>>> Hm. Ok. It still looks really weird. The comment in #midnight states that it answers midnight in the local time zone. That comment is now wrong, isn't it? #midnight now answers midnight UTC (??).
>>>
>>> In any case, I see two problems:
>>> 1. as already said, comparison operations on Date are broken (and on DateAndTime)
>>> 2. "midnight" is no longer the same as "midnight". Consider the following example:
>>>
>>> now := DateAndTime now.
>>> midnight := now - now hours hours - now minutes minutes - now seconds seconds - now nanoSecond nanoSecond.
>>> midnight = DateAndTime midnight "---> true"
>>>
>>> Interestingly, this evaluates to true in both 1.4 and 2.0. BUT: in 2.0 the objects have different julian day numbers and different seconds. I would hardly call those objects equal…
>>
>> thats a fully correct observation but a wrong conclusion :)
>>
>> old: internal, external representation and 0-point were local time
>> new: internal representation and 0-point are in UTC, external representation are in local time
>>
>> for comparisons we now simply compare the internal representation in UTC,
>> which makes everything way simpler.
>>
>>> I'm also pretty unhappy with the API changes to DateAndTime. For instance, "DateAndTime now seconds" is not the same as "DateAndTime now instVarNamed: 'seconds'". That's really frustrating when debugging those objects.
>>>
>>> Sorry Cami, I know that's your work :)
>>
>>
>> haha well consider it as one of these nasty things in pharo you got used to.
>> DateAndTime was sincerely broken in pre 2.0 images.
>> Moving an image between a timezone yielded wrong DateAndTimes (which btw happens
>> twice per year when switching from/to daylight saving time). The only way
>> to solve the mess is to have a fixed reference point, in this case UTC.
>>
>> - internally everything is in UTC
>> - externally everything is in local time
>>
>> believe me that was harder than you think ;) we did a nasty hackathon of 8hours
>> to get "everything" straight.
>>
>> That said, it might be confusing compared to pre 2.0 images but it makes definitely
>> more sense. Hence I can only conclude that the code you use from pre 2.0 era is wrong :D
>
>