[squeak-dev] Re: A UTC based implementation of DateAndTime
David T. Lewis
lewis at mail.msen.com
Wed Aug 27 00:17:00 UTC 2014
On Tue, Aug 26, 2014 at 04:21:09PM -0700, Sean P. DeNigris wrote:
> 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
> > 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.
The term "Date" can mean a lot of different things in different contexts,
so I think this is very much a matter of agreeing on definitions. As an
example, I work in the automotive manufacturing industry, where the term
"production date" has a very specific meaning that has very little to do
with time zones or specific points in time. But in general, most common
usage of the term "date" are meant to imply local time.
> 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
You are exactly right. As far as I am aware, there is no straightforward
way to use the C runtime libraries to obtain the offset for an arbitrary
time_t in the context of some specified time zone. So this is not something
that can be easily supported in a primitive. On the other hand, the current
offset in the current time zone is easily obtained, and that is now provided
by the the #primitiveUtcWithOffset primitive.
Fortunately, if you have access to the time zone rules, it is quite easy
to do these sorts of calculation in the image. This would typically be done
using the publicly available Olson time zone tables. Several implementations
have been done in Smalltalk, including the one that I did at
> 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).
I like that approach. Interestingly, if you look at an old version of Squeak
(ST-80), the Date class was implemented as you describe. It had no notion of
location or time zone. Maybe there is a better way now that we could represent
your PlatonicDate (aka ST-80?) such that it would collaborate with time zones and
DateAndTime, but possibly would not be tied to them in implementation.
More information about the Squeak-dev