[squeak-dev] Date hash is broken

Discussion:

Chris Cunningham

2018-10-17 14:35:46 UTC

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

Alistair Grant

2018-10-17 15:21:19 UTC

Permalink

Hi Chris,

Post by Chris Cunningham
Hi.
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,
Alist

Chris Cunningham

2018-10-17 16:25:16 UTC

Permalink

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

Post by Alistair Grant
Hi Chris,

Post by Chris Cunningham
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

Post by Chris Cunningham
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.
| 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

Alistair Grant

2018-10-17 16:34:52 UTC

Permalink

Hi Chris,

Post by Chris Cunningham
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

Post by Chris Cunningham
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

Post by Alistair Grant
Hi Chris,

I get true for both comparisons.
| 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)"

Chris Muller

2018-10-17 16:40:07 UTC

Permalink

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

Tobias Pape

2018-10-17 16:43:49 UTC

Permalink

Post by Chris Muller
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

Post by Chris Muller
Please read the class comment of both Date and DateAndTime.
On Wed, Oct 17, 2018 at 9:36 AM Chris Cunningham

Chris Muller

2018-10-17 18:03:35 UTC

Permalink

Post by Tobias Pape

Post by Chris Muller
DateAndTime now relates to a particular timezone, Date today does not.

Sorry, above ^^ I meant they are actually different magnitudes, not
just different types.

Post by Tobias Pape
(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

Post by Tobias Pape
Best regards
-Tobas

Post by Chris Muller
Please read the class comment of both Date and DateAndTime.
On Wed, Oct 17, 2018 at 9:36 AM Chris Cunningham

Chris Muller

2018-10-17 21:08:29 UTC

Permalink

I proposed a fix in the Inbox.

Chronology-Core-cmm.13.mcz

On Wed, Oct 17, 2018 at 9:36 AM Chris Cunningham

Post by Chris Cunningham

Hi.

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 ge

David T. Lewis

2018-10-17 23:11:44 UTC

Permalink

Post by Chris Cunningham
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
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 re