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