Maybe this happened with Squeak version 3.7?
http://wiki.squeak.org/squeak/1871
--Hannes
On 10/17/18, Richard O'Keefe <rao...@gmail.com> wrote:
> 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
>> >>
>> >
>>
>>
>>
>
