[squeak-dev] UTCDateAndTime discussion + Q&A
David T. Lewis
lewis at mail.msen.com
Tue Oct 23 01:02:57 UTC 2018
Hi Chris,
On Mon, Oct 22, 2018 at 04:30:52PM -0500, Chris Muller wrote:
> Hi Dave,
>
> Thanks for making UTCDateAndTime available on SqueakMap that "just
> works" -- not having to go research how to properly install it left me
> some time to actually start looking at it today.
>
> A cursory look reveals that, at least functionally, everything appears
> to be essentially the same as original Chronology except the on-going
> million-dollar question:
>
> What are the point-in-time endpoints of a timespan
> identified by a particular "Date"?
> There are two reasonable answers to this question:
>
> 1) "local" e.g., a period that begins from 12am to
> 11:59:59.999999 of my LOCAL time,
> or 2) "global" e.g., a period that begins from 12am to
> 11:59:59.999999 of UTC (offset 0).
>
> We already know that original Chronlology supports ability for
> applications to represent their Dates either way. What about
> UTCDateAndTime? When I do:
>
> DateAndTime now asDate = Date today
>
> I get "true", even though MY 22-Oct-2018 begins and ends at a
> different point-in-time than those in the UTC timezone..
>
> I realize most applications want a canonical representation of Dates,
> but where does this leave the timespan use-cases? Are they even
> possible at all? What if I truly need the same local representation
> of 22-Oct-2018 that everyone else recognizes in my local area?
>
I think the difference is when we get to Date class>>starting: which
sets the starting point to be aDateAndTime midnight.
In classic Chronology:
DateAndTime now asDate start ==> 2018-10-22T00:00:00-04:00
In UTCDateAndTime Chronology:
DateAndTime now asDate start ==> 2018-10-22T00:00:00+00:00
So I think you are right. Given that a date is modeled as a duration, the
start time of the date should align with the timezone of the DateAndTime
from which it was created.
The likely fix is to change DateAndTime>>midnight:
DateAndTime>>midnight
"Answer a DateAndTime starting at midnight of the same timezone offset as the receiver."
^ self class basicNew
setJdn: self julianDayNumber
seconds: 0
nano: 0
offset: (Duration seconds: localOffsetSeconds)
But fixing that triggers one other test failure so I need to sort that
out before posting anything.
Thanks for looking at this, much appreciated.
Dave
More information about the Squeak-dev
mailing list
|