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

The Timespan class>>localize approach looks problematic. It is caching
a localOffset value, and this value may or may not match that of the
offset in the TimeZone.

The current offset from UTC is a function of time (it changes at
daylight savings transitions) and it is a function of local time zone
(which changes whenever an image is opened in a different time zone).
For this reason, caching an offset in Timespan would lead to errors
whenever the current offset from UTC changes.

Squeak sets its time zone offset at image startup time, so for most
people the errors would be seen after restarting an image following
a daylight savings transition, or after restarting an image on a
platform with a different time zone (e.g. someone downloads an image
that had been saved in some different time zone). If the time zone is
set to a time zone in TimeZoneDatabase (i.e. an Olsen time zone table),
then the current UTC offset is calculated in real time and changes
at the actual time of daylight savings transitions. An offset that
is cached in Timespan would become invalid in any of these cases.

Dave

> 
> 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.