If you're on 1.4 you have serious issues when moving between timezones
(in this case the winter/summer time switch)

see https://code.google.com/p/pharo/issues/detail?id=5919
and http://forum.world.st/Bug-in-DateAndTime-td2293749.html

the problem is, that the reference point was not defined in a fixed time-zone
but rather relative, which breaks under certain conditions!!


On 2012-10-30, at 22:20, Paul DeBruicker <[email protected]> wrote:
> Sabine Knöfel wrote
>> I have an attribute "date" in a domain object. Last week, I created some
>> objects with this attribute. Today I created objects again with the same
>> date value in this attribute. When comparing the dates (=), the result is
>> false. 
>> 
>> Reason is, that in germany, we had a switch from Central European Summer
>> Time (CEST) (Sommerzeit) to Daylight Saving Time (DST) this weekend.
>> 
>> Date has an attribute "start" which has an instance of DateAndTime. This
>> DateAndTime object has another value depending on the CEST/DST
>> 
>> 2012-10-02T00:00:00+
> *
>> 01:00
> *
>> (DST)
>> 2012-10-02T00:00:00+
> *
>> 02:00
> *
>> (CEST)
>> 
>> When I create two Dates with same date, I expect that = evaluates to true,
>> independent from the CEST/DST. But Date (Timespan) uses 
> /
>> = comparand
>>      ^ self class = comparand class 
>>              and: [ 
> *
>> self start = comparand start 
> *
>>                              and: [ self duration = comparand duration ]]
> /
>> 
>> 
>> What do you recommend? Create my own compare method? Did I miss something?
> 
> 
> Localized dates and times are awful to mess with because the timing of the
> daylight savings transitions are political and vary from place to place and
> year to year.
> 
> This is good advice from Tom Rushworth on comparing dates:
> http://forum.world.st/Should-Dates-be-Timezone-specific-tp3647678p3649107.html
> 
> Also on Squeaksource the TimeZoneDatabase and Chronos packages have
> mechanisims for keeping up to date about when offsets should be changed in
> the image.  
> 
> For me, my image's internal timezone is set to UTC. I use Chronos and store
> everything as UTC, use UTC values for every calculation, then convert it
> back to the local time only on display to a user.  
> 
> 
> 
> --
> View this message in context: 
> http://forum.world.st/Problem-with-Date-comparing-summer-time-CEST-tp4653354p4653383.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
> 


Reply via email to