On Fri, Feb 03, 2012 at 06:35:02PM -0600, Chris Muller wrote:
> > Chris, makeUTC already solved your both problems right?
> > - it makes Date comparable, even when coming from DateAndTime of
> > different time zone
> > - it makes hash fast enough
> 
> Thanks Nicolas.  I actually have 37 senders of it in my financial app
> which has become intolerable.  So I think makeUTC started out as a
> quick-fix to address those issues and get me by until I could think
> more about it.
> 
> Now I believe I have a good solution in the Inbox.
> 
> > I also notice that the offset used to create a DateAndTime is NOT
> > taken into account when extracting the Date...
> > The Date is always extracted with local time zone which is ... weird.
> 
> Agreed.  So international-systems that need Timezone-sensitive Dates
> are all mixed up -- because it wants to always create them in the
> local-offset of the running computer regardless of the timezone of the
> source data.
> 
> I've changed that.  Now, Timespan offsets are cascaded forward from
> their source -- whether that source be a DateAndTime, another
> Timespan, or a user-specification (e.g., method argument).
> 
> When the offset is not specified, it will look to a new class-instance
> variable:  'defaultOffset'.
> 
> The default value for defaultOffset must be Duration zero not just for
> optimal hashing, but also so that more unsuspecting Squeakers besides
> me and Jon don't get bitten so badly.  In my case, offset differences
> in Date objects resulted in arithmetic testing to choose the wrong
> logic paths.  There was no blow up, just corrupt data.  Ouch!
> 
> The legacy behavior, Dates that start at midnight of the local-offset
> can be gotten by simply updating the defaultOffset thusly:
> 
>      Date localize
> 
> All tests pass except maybe not Timespan since its going to be purged.
>  I'm going to chew on it for at least week -- if anyone wants to test
> their app that'd be good too.

I have not looked at this carefully, but after loading the update I get
27 failures and 7 errors running TimeTransformTest from TimeZoneDatabase,
out of a total of 526 tests that should all pass.

I'm struggling to understand why "Date today" should be a TimeSpan that
begins at some time other than midnight in my local time zone. The date
that I think of as "4 February 2012" began about 20 minutes ago here in
Detroit, but in London and Paris it is old news.

With the inbox update loaded, and using PointInTime to do the conversions:

  Date today start ==> 2012-02-04T00:00:00+00:00

  Date today start asPointInTime asDateAndTime ==> 2012-02-03T19:00:00-05:00

This would mean that "Date today" began at 7:00pm yesterday, rather than
at 12:00 midnight. I understand that this makes it easier to compare date
objects, but ...

Dave