Oh my, I didn't know we had that bug too!  Yes, we will definitely
want to include that, too, since people might want to be able to join
trunk development!

We could either freshen the images or just hope the user clicks on
"Update Squeak".  Personally, I think we should put out a new set of
images, but I don't know how to do that myself.  Fabio is that you?
Would you be willing to push them one more time?

Bert, are you going to be okay with this fix at least for now?  Chris
Cunningham's explanation of why updating #hash to not account for
offset was an excellent analysis of why it may not be the best idea.
We should just go back to hard types for now.  I will add one more set
of convenience methods to Timespan make this even easier and
more-explicit...   (e,g,, #asDatespan   ^ self asDate).

 - Chris
On Fri, Oct 19, 2018 at 8:56 AM Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> Hi Chris,
>
> > On Oct 18, 2018, at 7:10 PM, Chris Muller <asqueaker at gmail.com> wrote:
> >
> > It's a really bad bug, we should backport the fix to the new 5.2
> > release ASAP hopefully before the News announcement.
>
> If we’re going to “freshen” the 5.2 release we should do it quickly and be sure to include my fix to preferences that allows one to change the update URL.
>
> >
> > In the meantime, a fix is available by loading
> > Chronology-Core-cmm.15.mcz from the Inbox.  With that you can do
> > everything.  No limitations, just be sure when you use #asDate on a
> > DateAndTime, since its a date that originated from a
> > timezone-sensitive object, it retains that timezone, so if you want to
> > use it in a system of canonical dates, you need to convert it by
> > sending either #beCanonical or #stripTimezone (whichever you prefer),
> > then it will compare equally with the one from "Date today" (which
> > always produces a canonical date).
> >
> > - Chris
> >> On Thu, Oct 18, 2018 at 8:04 PM Tim Johnson <digit at sonic.net> wrote:
> >>
> >> Hi,
> >>
> >> I am very grateful to see the discussions about timezones on the list
> >> recently, because I just got hit by it today.
> >>
> >> I couldn't figure out why a Set containing Date objects didn't properly
> >> detect membership of a Date which was clearly present in the Set. It was
> >> because, I realize now, the Date objects in the Set had an offset of
> >> -0:07:00:00 (they are created by DateAndTime>>#now), and Dates created
> >> by e.g. "Date today" or "Date yesterday" either have no offset or the
> >> offset is 0:00:00:00.  I have found the comment in Timespan
> >> class>>#defaultOffset -- but it does not encourage me that I could
> >> change my defaultOffset to help myself.
> >>
> >> In my tests (code snippet below), if I make an OrderedCollection from
> >> the Set, the OrderedCollection can find the date object, even though the
> >> Set can't.
> >>
> >> In the Mean Time (get it?), can I create Dates with offsets?
> >> "(DateAndTime now - 1 day) asDate" works...?  Or are there any other
> >> workarounds?  Should I walk away from Date and use something else?
> >>
> >> Thanks!
> >>
> >> (in a Workspace)
> >> | dates |
> >> dates := Set newFrom: { Date yesterday. Date tomorrow.  DateAndTime now
> >> asDate }.
> >> dates includes: (Date year: 2018 month: 10 day: 18).   "=> false"
> >> dates asOrderedCollection includes: (Date year: 2018 month: 10 day: 18).
> >>  "=> true"
> >>
> >>
> >> (in an inspector on a Set of dates with offsets)
> >> | a m |
> >> a := Date year: 2018 month: 10 day: 17.
> >> self includes: a.                               "-> false"
> >> self like: a.                                   "-> nil"
> >> self asOrderedCollection includes: a.  "-> true"
> >> m := self array at: 4.          "-> 17 October 2018"
> >> m start offset.                         "-> -0:07:00:00"
> >> a start offset                          "-> 0:00:00:00"
> >>
> >>
> >
>