[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