There is an elephant in the room. Historically and in Smalltalks such as
GNU Smalltalk, Smalltalk/X, my Smalltalk->C system, VisualAge Smalltalk,
and VisualWOrks, a Date is *not* a TimeSpan and is *not* associated with
a time zone or a zone offset. It's generally a direct subclass of
Magnitude. And this was originally true in Squeak as well. I just had a
look at SqueakV2.source to verify that.
At some point subsequent to the 2.x series, Squeak made an incompatible
and to me incomprehensible change, with the result that "Date" in today's
Squeak and Pharo is incompatible with every other Smalltalk I've been able
to check: it does not mean the same thing any more and cannot be used the
same ways.
The "classic" semantics is that a Date represents a cultural item, a day
in the proleptic Gregorian calendar, without reference to any particular
locality. For example, my most recent birthday was 2018-10-11, and it
would have been the same *date* but not the same *timespan* no matter
where I was in the world. The USA celebrated President's day on
2018-02-19 this year, and it was the same *date* in every state, but
by no means the same *timespan*.
Now, granting the utility of a class to represent the timespan associated
with a date in a given timezone, the obvious way to introduce it would
have been to introduce a new DateInZone class. Sadly, in Squeak the
Date class was changed incompatibly to take that role, with nothing left
to do what Date usefully did (and still does elsewhere).
So now we have the problem that the original poster wanted to do
something perfectly sensible that works in nearly every other Smalltalk
and used to work in Squeak, but it doesn't work in Pharo.
In this situation, I'd be strongly inclined to port say GNU Smalltalk's
Date class, renaming it to CompatibleDate, add a global variable
DateInZone, and add methods
CompatibleDate>>inZone:
DateInZone>>sansZone
On Wed, 17 Oct 2018 at 09:44, Sven Van Caekenberghe <s...@stfx.eu> wrote:
>
>
> > On 16 Oct 2018, at 22:27, Alistair Grant <akgrant0...@gmail.com> wrote:
> >
> > Hi Petr,
> >
> > On Tue, 16 Oct 2018 at 21:25, Petr Fischer via Pharo-users
> > <pharo-users@lists.pharo.org> wrote:
> >>
> >> My problem - use Dates as Dictionary keys - shortly:
> >>
> >> d1 := Date today translateToUTC.
> >> d2 := Date today.
> >>
> >> d1 = d2. (true!)
> >
> > Which timezone are you in?
> >
> > CEDT (UTC+0200) gives false for this.
> >
> > Date is implemented primarily as a timespan, so days in different
> > timezones are considered different. If you do:
> >
> > | d1 d2 |
> >
> > d1 := Date today translateTo: (TimeZone abbreviated: 'UTC') offset.
> > d2 := Date today translateTo: (TimeZone abbreviated: 'EST') offset.
> >
> > { d1 = d2. d1 equals: d2 }
> >
> >
> > You can see the difference.
> >
> > Of course, this doesn't help with using Date as a key in a dictionary.
> > Probably your best option is to look at Sven's excellent ZTimezone
> > package (although I haven't tested it in this scenario).
> >
> > I can't find the repository right now (I think Sven moved it to
> github). Sven?
>
> It is called ZTimestamp and it lives in various places, for example:
> https://github.com/svenvc/ztimestamp
>
> > Cheers,
> > Alistair
> >
> >
> >
> >> d := Dictionary new.
> >> d at: d1 put: 1.
> >>
> >> d at: d1. (ok)
> >> d at: d2. (bad - key not found)
> >>
> >> ---
> >>
> >> pf
> >>
> >
>
>
>
