David T. Lewis wrote
the two main responsibilities of DateAndTime. One is to represent time as a magnitude (for duration calculation, etc). The other is to display time in the frame of reference of a local time zone. It is not at all clear to me that those two responsibilies belong in the same class.
There is definitely something fishy with the combination. Consider Pharo's Date, which retroactively applies the current timezone to dates. This is bad because e.g.: '7/10/2014' asDate "evaluated the day before DST" ~= '7/10/2014' asDate "evaluated the day after DST"
I created an issue, which has been sitting on the bug tracker. Here's an excerpt from the discussion (https://pharo.fogbugz.com/default.asp?12147#BugEvent.90264):
I see that a particular location could reasonably be implied in a Date, e.g. if we're saying that a treaty was signed on such and such a date, we mean at the place where it was signed... it may have already been the next day in another time zone.
Now, what is beyond doubt, is that the timezone that would be implied is the timezone of the date itself, not an artifact of when the instance was created. In my example, I create '11/12/2013' asDate, and it assumes my timezone. Since it's the summer in NY, that means -4 offset. Now, I evaluate '11/12/2013' asDate again in December. Again it implies my timezone, the offset of which has changed to -5! So now '11/12/2013' asDate (in NY) ~= '11/12/2013' asDate (in NY). Even though the offset of the date in question, which depends only on whether DST was in effect on 11/12/2013, has not changed.
So the current behavior of two equal dates being considered not-equal is as jarring as your counter example of two non-equal dates (different timezone) being considered equal.
There doesn't seem to be an easy, direct solution because I'm assuming we don't have a primitive for "the offset at this location on X date in the past". So the next best thing might be a PlatonicDate (obviously a name-in-progress :)) that represents the abstract idea of a Date without regard to location, and then an object to connect a particular place/offset to that concept (but the second one would have the same problem as we currently have).
----- Cheers, Sean -- View this message in context: http://forum.world.st/What-s-up-on-build-squeak-org-tp4760266p4774978.html Sent from the Squeak - Dev mailing list archive at Nabble.com.