[squeak-dev] The Inbox: Chronology-Core-cmm.13.mcz

Chris Cunningham cunningham.cb at gmail.com
Thu Oct 18 03:36:08 UTC 2018


Ok, the comments that I remembered where in the Timespan>>defaultOffset
that described the behaviour that #= was exhibiting.  That is, it is
intentional - wheither right or not, it is intentional, and this comment
needs to change when we change #= or #hash.

"Timespans created in the context of an offset will start in that offset.
When no context is available, the defaultOffset for Timespans must be nil.
For example, two ways to make a Date for today:
Date today.  'start is midnight without offset.  Will compare successfully
to other Date today results.'
DateAndTime now asDate.  'In this case, the start is midnight of the local
time-zone.  It can only compare equally to Dates of its time-zone or Dates
without timezone.'"

That last part - "[DateAndTime now asDate] can only compare equally to Date
of its time-zone or Dates without timezone."  This change makes the last
part of that sentence incorrect.

Summary of below - I agree with this change after thinking about it for a
while.  I do think that the comment above needs to change.

Having read Richard's email (referenced by David), I would also like a Date
to just be a Date, and you can compare any Date to another Date for the
same day and they are the same.  At the same time, I would like (and need
to know) if a timestamp in one part of the world occurred on a specific
date in another part of the world - and with just a Magnitude Date, this is
hard (that is, I have to convert the timestamp to the other part of the
world, stored somewhere separately from Date but linked to it, and then see
if it is still the same Date.  Much easier with Dates the way they are).

My first inclination to fix this is that any date should compare to any
other date if the date part of the start is the same - basically, ignore
the offset and just check that the ticks are the same.  (For Dates, we
could also ignore the duration - it is a DAY, not a random duration, after
all.  But if we did this, we'd have to verify both are Date class - so skip
that idea.)

The problem with this is that two days starting in different parts of the
world may not overlap a lot, and if we care about the actual day duration,
that would not be nice.

After validating a few more things:
   Date today start offset "0:00:00:00"
   '2018-10-07' asDate start offset "0:00:00:00"
   DateAndTime now asDate start offset "-0:07:00:00"
   '2018-10-17 00:00:00' asDate start offset "0:00:00:00"
I think that the change is about right.  I'll just have to live with Dates
built off of times from different parts of the world are, in fact,
different Dates.  If I want a 'Date' that works like the older Smalltalks,
I can craft a very similar one by nil'ing out the offset of any Date.

This is also a better answer than just delegating the time comparison to
start (DateAndTime), the offset gets weird in that case.  For example:

I do find it interesting that Timespan's with not offset, when asked the
offset, return an offset that looks like UTC, though.
  DateAndTime now makeUTC asDate = Date today "true"
  DateAndTime now makeUTC asDate hash = Date today hash "true"

========
Once this (or an equivalent fix) is in, I'm going to take a shot at fixing
DateAndTime>>= - it is doing up to 3 #isKindOf: comparisons (!) in that
method.  Crazy.

Thanks,
-cbc

On Wed, Oct 17, 2018 at 6:26 PM Chris Cunningham <cunningham.cb at gmail.com>
wrote:

> I'm not so sure. at the very least you will need to change the comment
> because it specifically states this isn't what should be done.
>
> when I get back from the water polo game I'll give a better argument (or
> retract my statement).
>
> On Wed, Oct 17, 2018, 17:43 David T. Lewis <lewis at mail.msen.com> wrote:
>
>> If I am reading this right, it says that we can test for
>> "self start = comparand start" if and only if both of the two Timespans
>> have no timezone information, otherwise we need to use #hasEqualTicks:
>> to compare the two start values for the two durations.
>>
>> I'm not sure if there is an optimization available for the case of the
>> two Timespans both having timezone information, but aside from that
>> the change looks right to me.
>>
>> Dave
>>
>> On Wed, Oct 17, 2018 at 09:04:29PM +0000, 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.13.mcz
>> >
>> > ==================== Summary ====================
>> >
>> > Name: Chronology-Core-cmm.13
>> > Author: cmm
>> > Time: 17 October 2018, 4:04:08.832696 pm
>> > UUID: 60718249-84a8-4dc2-aa94-4ba5c8e5addc
>> > Ancestors: Chronology-Core-tcj.12
>> >
>> > Fix DateAndTime today asDate = Date today even when not in GMT.
>> >
>> > =============== Diff against Chronology-Core-tcj.12 ===============
>> >
>> > Item was changed:
>> >   ----- Method: Timespan>>= (in category 'ansi protocol') -----
>> >   = comparand
>> >       ^ self class = comparand class
>> > +             and: [((self noTimezone and: [comparand noTimezone])
>> > -             and: [((self noTimezone or: [ comparand noTimezone ])
>> >                       ifTrue: [ self start hasEqualTicks: comparand
>> start ]
>> >                       ifFalse: [ self start = comparand start ])
>> >               and: [ self duration = comparand duration ] ]
>> >   .!
>> >
>> >
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20181017/5460ab48/attachment.html>


More information about the Squeak-dev mailing list