Maybe this happened with Squeak version 3.7? http://wiki.squeak.org/squeak/1871 --Hannes On 10/17/18, Richard O'Keefe <raoknz@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 <sven@stfx.eu> wrote:
On 16 Oct 2018, at 22:27, Alistair Grant <akgrant0710@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