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