[squeak-dev] Re: A UTC based implementation of DateAndTime

Sean P. DeNigris sean at clipperadams.com
Tue Aug 26 23:21:09 UTC 2014


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.


More information about the Squeak-dev mailing list