[squeak-dev] About the new Date

Chris Muller ma.chris.m at gmail.com
Thu Feb 9 16:36:55 UTC 2012


An alternate solution if we truly need localized-Dates would be just
to cache a boolean instead of the offset itself:  #localizedByDefault.
 If true, it would use the common #localOffset rather than caching its
own.

Either way is fine with me.

 - Chris


On Thu, Feb 9, 2012 at 5:59 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> 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.


More information about the Squeak-dev mailing list