Hey Bert,

I just noticed what you added to the very end of that comment in
Timespan class>>#defaultOffset, where you added:

      "It can only compare equally to Dates of its time-zone or Dates
without timezone."

I didn't know (or remember) that's what you were trying to do until
just now!  It seems like a cool idea, but it seems impossible due to
the #hash vs. #= problem.  Hmmm...

I think apps will have to send #beCanonical if they want canonical
Dates from DateAndTime's...

 - Chris
On Thu, Oct 18, 2018 at 12:27 PM Bert Freudenberg <bert at freudenbergs.de> wrote:
>
> I'm not sure this is right.
>
> The current implementation comes from the "trunk thinks its tomorrow" discussion starting on 17 Feb 2016. As a result we introduced the "noTimezone" notion: a date without timezone compares equal to the same date in any time zone. At some point this made all the tests green.
>
> - Bert -
>
> On Wed, Oct 17, 2018 at 8:53 PM Chris Cunningham <cunningham.cb at gmail.com> wrote:
>>
>> I like this.
>>
>> Although I notice that the comparison makes sure that the classes are the same - so a Timespan starting at the exact same time as a Date and with 24 hour duration is not the same as a Date with the exact same values.
>>
>> This would allow further speedups if Date, Week, Month, and Year if we wanted - just drop the comparison of duration in those classes.  (The general case is still needed to tell Timespan apart from Schedule.)
>>
>> If you did that, you probably also want to re-implement hash as well - simplifying it the same way.
>>
>> -cbc
>>
>> On Wed, Oct 17, 2018 at 8:07 PM <commits at source.squeak.org> wrote:
>>>
>>> Chris Muller uploaded a new version of Chronology-Core to project The Inbox:
>>> http://source.squeak.org/inbox/Chronology-Core-cmm.14.mcz
>>>
>>> ==================== Summary ====================
>>>
>>> Name: Chronology-Core-cmm.14
>>> Author: cmm
>>> Time: 17 October 2018, 10:07:14.485014 pm
>>> UUID: 5d93900c-4a4e-4a4e-80f3-800dbdb07d0b
>>> Ancestors: Chronology-Core-tcj.12
>>>
>>> - A fix and optimization of Timespan>>#=.  Both elements being compared must have the same timezone (or same state of #noTimezone) in order to take advantage of the optimized #hasEqualTicks: comparison.  Otherwise (if different timezones), a full comparison of their starts (via #=) is needed.
>>> - There was a mention of this optimization put into the class comment.  This level of detail may be a bit tedious for users to read at that level, so Brents original comment was restored.
>>>
>>> =============== Diff against Chronology-Core-tcj.12 ===============
>>>
>>> Item was changed:
>>>   Magnitude subclass: #Timespan
>>>         instanceVariableNames: 'start duration'
>>>         classVariableNames: ''
>>>         poolDictionaries: ''
>>>         category: 'Chronology-Core'!
>>>
>>> + !Timespan commentStamp: 'cmm 10/17/2018 22:00' prior: 0!
>>> + I represent a duration starting on a specific DateAndTime.!
>>> - !Timespan commentStamp: 'bf 2/18/2016 14:43' prior: 0!
>>> - I represent a duration starting on a specific DateAndTime.
>>> -
>>> - If my start has an offset identical to my #defaultOffset then comparisons ignore timezone offset.!
>>>
>>> Item was changed:
>>>   ----- Method: Timespan>>= (in category 'ansi protocol') -----
>>>   = comparand
>>> +     ^ self class = comparand class
>>> +         and: [(((self noTimezone and: [comparand noTimezone]) or: [self start offset = comparand start offset])
>>> +             ifTrue: [ self start hasEqualTicks: comparand start ]
>>> +             ifFalse: [ self start = comparand start ])
>>> +         and: [ self duration = comparand duration ] ]
>>> -       ^ self class = comparand class
>>> -               and: [((self noTimezone or: [ comparand noTimezone ])
>>> -                       ifTrue: [ self start hasEqualTicks: comparand start ]
>>> -                       ifFalse: [ self start = comparand start ])
>>> -               and: [ self duration = comparand duration ] ]
>>>   .!
>>>
>>>
>>
>