Date hash is broken
Locked
 
|
Hi. Following a thread in Pharo where two dates that are equal weren't usable in a Dictionary as keys, I wondered if the same thing is true in Squeak. It is, unfortunately. I can't use the same code as given in the Pharo example (we don't have a #translateToUTC), but equivalent code shows the issue: d1 := DateAndTime now asDate. d2 := Date today. d1 = d2. "true" d1 hash = d2 hash. "false" I'll get around to fixing the hash in the next day or so, when I get a chance to figure out how. Thanks, cbc |
|
|
Hi Chris,
On Wed, 17 Oct 2018 at 16:36, Chris Cunningham <[hidden email]> wrote: > > Hi. > > Following a thread in Pharo where two dates that are equal weren't usable in a Dictionary as keys, I wondered if the same thing is true in Squeak. It is, unfortunately. I can't use the same code as given in the Pharo example (we don't have a #translateToUTC), but equivalent code shows the issue: > > d1 := DateAndTime now asDate. > d2 := Date today. > d1 = d2. "true" > d1 hash = d2 hash. "false" > > I'll get around to fixing the hash in the next day or so, when I get a chance to figure out how. I get true for both comparisons. What's the result of: | d1 d2 | d1 := DateAndTime now asDate. d2 := Date today. { d1 = d2. d1 hash = d2 hash. d1 start. d1 duration. d2 start. d2 duration. } " an Array( true true 2018-10-17T00:00:00+02:00 1:00:00:00 2018-10-17T00:00:00+02:00 1:00:00:00)" Cheers, Alistair |
|
|
Hi Alistair, which version of Squeak are you using? The latest version I get {true . false . 2018-10-17T00:00:00-07:00 . 1:00:00:00 . 2018-10-17T00:00:00+00:00 . 1:00:00:00} from the results of your script. Maybe you are using Pharo? Back in Feb 2016 the default offset for timespans (and hence the default offset for Date) was set to nil - meaning for the display the Date today should show +0:00 (which is not nil, obviously, but prints better). -Chris On Wed, Oct 17, 2018 at 8:21 AM Alistair Grant <[hidden email]> wrote: Hi Chris, |
|
|
Hi Chris,
On Wed, 17 Oct 2018 at 18:25, Chris Cunningham <[hidden email]> wrote: > > Hi Alistair, > > which version of Squeak are you using? This was in Pharo 7 - I thought you'd said that the same issue exists in both Pharo and Squeak. But: In squeak Timespan>>= doesn't match Timespan>>hash, so it does indeed need to be made consistent. Cheers, Alistair > The latest version I get > {true . false . 2018-10-17T00:00:00-07:00 . 1:00:00:00 . 2018-10-17T00:00:00+00:00 . 1:00:00:00} > from the results of your script. Maybe you are using Pharo? Back in Feb 2016 the default offset for timespans (and hence the default offset for Date) was set to nil - meaning for the display the Date today should show +0:00 (which is not nil, obviously, but prints better). > > -Chris > > On Wed, Oct 17, 2018 at 8:21 AM Alistair Grant <[hidden email]> wrote: >> >> Hi Chris, >> >> On Wed, 17 Oct 2018 at 16:36, Chris Cunningham <[hidden email]> wrote: >> > >> > Hi. >> > >> > Following a thread in Pharo where two dates that are equal weren't usable in a Dictionary as keys, I wondered if the same thing is true in Squeak. It is, unfortunately. I can't use the same code as given in the Pharo example (we don't have a #translateToUTC), but equivalent code shows the issue: >> > >> > d1 := DateAndTime now asDate. >> > d2 := Date today. >> > d1 = d2. "true" >> > d1 hash = d2 hash. "false" >> > >> > I'll get around to fixing the hash in the next day or so, when I get a chance to figure out how. >> >> I get true for both comparisons. >> >> What's the result of: >> >> | d1 d2 | >> >> d1 := DateAndTime now asDate. >> d2 := Date today. >> { >> d1 = d2. >> d1 hash = d2 hash. >> d1 start. >> d1 duration. >> d2 start. >> d2 duration. } >> >> " an Array( >> true >> true >> 2018-10-17T00:00:00+02:00 >> 1:00:00:00 >> 2018-10-17T00:00:00+02:00 >> 1:00:00:00)" >> >> Cheers, >> Alistair >> > |
|
|
In reply to this post by cbc
Nothing is broken in that example. They are truly different.
DateAndTime now relates to a particular timezone, Date today does not. Please read the class comment of both Date and DateAndTime. On Wed, Oct 17, 2018 at 9:36 AM Chris Cunningham <[hidden email]> wrote: > > Hi. > > Following a thread in Pharo where two dates that are equal weren't usable in a Dictionary as keys, I wondered if the same thing is true in Squeak. It is, unfortunately. I can't use the same code as given in the Pharo example (we don't have a #translateToUTC), but equivalent code shows the issue: > > d1 := DateAndTime now asDate. > d2 := Date today. > d1 = d2. "true" > d1 hash = d2 hash. "false" > > I'll get around to fixing the hash in the next day or so, when I get a chance to figure out how. > > Thanks, > cbc > |
|
|
> On 17.10.2018, at 18:40, Chris Muller <[hidden email]> wrote: > > Nothing is broken in that example. They are truly different. > > DateAndTime now relates to a particular timezone, Date today does not. Yet, the following must hold: (a = b) ==> (a hash = b hash) We need to change something. Maybe we need #isSameDayAs: instead of =…, or so Best regards -Tobas > > Please read the class comment of both Date and DateAndTime. > On Wed, Oct 17, 2018 at 9:36 AM Chris Cunningham > <[hidden email]> wrote: >> >> Hi. >> >> Following a thread in Pharo where two dates that are equal weren't usable in a Dictionary as keys, I wondered if the same thing is true in Squeak. It is, unfortunately. I can't use the same code as given in the Pharo example (we don't have a #translateToUTC), but equivalent code shows the issue: >> >> d1 := DateAndTime now asDate. >> d2 := Date today. >> d1 = d2. "true" >> d1 hash = d2 hash. "false" >> >> I'll get around to fixing the hash in the next day or so, when I get a chance to figure out how. >> >> Thanks, >> cbc >> > |
|
|
> > DateAndTime now relates to a particular timezone, Date today does not.
Sorry, above ^^ I meant they are actually different magnitudes, not just different types. > Yet, the following must hold: > > (a = b) ==> (a hash = b hash) Woops! I didn't notice the last line comparing the hashes! That IS a problem. This is a case where "browse origin" comes in handy. It appears we broke it in this series of packages: __________________________ Name: Kernel-bf.991 Author: bf Time: 17 February 2016, 6:33:53.746681 pm UUID: 1d2c150b-bafd-43be-a1ea-648007f13215 Ancestors: Kernel-dtl.990 Use proper timezone in DateAndTime now. __________________________ Name: Kernel-bf.994 Author: bf Time: 18 February 2016, 2:59:01.974843 pm UUID: e47a7687-8244-43f0-b608-3f0759ac382d Ancestors: Kernel-eem.993 Make Timespan explicitly ignore its start's timezone offset if it was created with the defaultOffset. __________________________ Name: Chronology-Core-cmm.3 Author: cmm Time: 18 March 2016, 1:31:09.337847 pm UUID: 4e36f7ad-aa95-433a-bb7f-198798b81942 Ancestors: Chronology-Core-cmm.2 - When the localTimeZone is explicitly updated by the user, ensure the system does not silently change it back if the user didn't remember to also turn off automaticTimeZone:. - Added DateAndTime class>>#nowAtOffset: to obtain the local time at other places than the localTimeZone. __________________________ __________________________ __________________________ Oh boy, I remember this... after all that battling we did... to come out with a bug like this. Sad... Yeah, we gotta get this fixed. Folks, for something like this I request that we please start our solutions out in the Inbox please. Thanks for your understanding. Best, Chris > > Best regards > -Tobas > > > > > Please read the class comment of both Date and DateAndTime. > > On Wed, Oct 17, 2018 at 9:36 AM Chris Cunningham > > <[hidden email]> wrote: > >> > >> Hi. > >> > >> Following a thread in Pharo where two dates that are equal weren't usable in a Dictionary as keys, I wondered if the same thing is true in Squeak. It is, unfortunately. I can't use the same code as given in the Pharo example (we don't have a #translateToUTC), but equivalent code shows the issue: > >> > >> d1 := DateAndTime now asDate. > >> d2 := Date today. > >> d1 = d2. "true" > >> d1 hash = d2 hash. "false" > >> > >> I'll get around to fixing the hash in the next day or so, when I get a chance to figure out how. > >> > >> Thanks, > >> cbc > >> > > > > |
|
|
In reply to this post by cbc
I proposed a fix in the Inbox.
Chronology-Core-cmm.13.mcz On Wed, Oct 17, 2018 at 9:36 AM Chris Cunningham <[hidden email]> wrote: >> Hi. > > Following a thread in Pharo where two dates that are equal weren't usable in a Dictionary as keys, I wondered if the same thing is true in Squeak. It is, unfortunately. I can't use the same code as given in the Pharo example (we don't have a #translateToUTC), but equivalent code shows the issue: > > d1 := DateAndTime now asDate. > d2 := Date today. > d1 = d2. "true" > d1 hash = d2 hash. "false" > > I'll get around to fixing the hash in the next day or so, when I get a chance to figure out how. > > Thanks, > cbc > |
|
|
In reply to this post by cbc
On Wed, Oct 17, 2018 at 07:35:46AM -0700, Chris Cunningham wrote:
> Hi. > > Following a thread in Pharo where two dates that are equal weren't usable > in a Dictionary as keys, I wondered if the same thing is true in Squeak. > It is, unfortunately. I can't use the same code as given in the Pharo > example (we don't have a #translateToUTC), but equivalent code shows the > issue: > > d1 := DateAndTime now asDate. > d2 := Date today. > d1 = d2. "true" > d1 hash = d2 hash. "false" > > I'll get around to fixing the hash in the next day or so, when I get a > chance to figure out how. > > Thanks, > cbc Related to this issue, I would like to point out a post by Richard O'Keefe in that same discussion on the Pharo list: http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2018-October/040980.html This is very much worth reading, as it provides a clear explanation of a conceptual (not technical) problem that leads to side-effect issues such as the one under discussion here. I am not advocating making any changes, just recommending that interested Squeakers read Richard's post. Dave |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |