[Pharo-project] 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
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 <maxleske@gmail.com> 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
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 <camillobruni@gmail.com> 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 <maxleske@gmail.com> 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
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 <camillobruni@gmail.com> 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 <camillobruni@gmail.com> 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 <maxleske@gmail.com> 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, On 30 Dec 2012, at 09:42, Max Leske <maxleske@gmail.com> 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 <camillobruni@gmail.com> 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 <camillobruni@gmail.com> 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 <maxleske@gmail.com> 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
On 30.12.2012, at 10:50, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Max,
On 30 Dec 2012, at 09:42, Max Leske <maxleske@gmail.com> 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 <camillobruni@gmail.com> 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 <camillobruni@gmail.com> 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 <maxleske@gmail.com> 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
On 2012-12-30, at 05:42, Max Leske <maxleske@gmail.com> 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 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 <maxleske@gmail.com> 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
On 2012-12-30, at 10:26, Stéphane Ducasse <stephane.ducasse@inria.fr> 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 ;)
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 <camillobruni@gmail.com> wrote:
On 2012-12-30, at 05:42, Max Leske <maxleske@gmail.com> 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
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 <camillobruni@gmail.com> wrote:
On 2012-12-30, at 05:42, Max Leske <maxleske@gmail.com> 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
participants (4)
-
Camillo Bruni -
Max Leske -
Stéphane Ducasse -
Sven Van Caekenberghe