2014-08-27 1:21 GMT+02:00 Sean P. DeNigris <sean at clipperadams.com>:

> 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):
>
>
For me, this is definitely a bug.
In current implementation, the date corresponding to a DST change should be
either 23h or 25h long,
and this should not depend on active DST at the time you ask.

Of course, if we go into these complications, what to do when the DST rules
change, but we ask for a Date anterior to the change?
Shall we store/maintain the DST rule history for each and every part of the
world?


> 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).
>
>
>
Of course, a PlatonicDate would be so much simpler...
It's a different thing though.



>
> -----
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140827/84e05bab/attachment.htm