David T. Lewis wrote
> the two main responsibilities of DateAndTime. One isThere is definitely something fishy with the combination. Consider Pharo's
> 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.
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.