What is missing in the current Pharo image is a field based
Date/DateTime instead of an offset+duration one as it currently is.

Why not use Chronos instead? AFAIR Chronos provides that.

An alternative would be to implement a "Calendar" (as in
Java.util.Calendar [1]), that can exist in parallel with the existing
Date class.

Regards,

[1] https://developer.android.com/reference/java/util/Calendar.html

On 10/04/2018 03:30, Stephane Ducasse wrote:
> Hi Paul
> 
> I agree and instead of patching the current system I would start using
> TDD to design
> a new Date package.
> 
> stef
> 
> On Mon, Apr 9, 2018 at 8:42 PM, Paul DeBruicker <pdebr...@gmail.com> wrote:
>> I  think #= is a bad selector for Date and should be avoided when determining
>> whether something happens on a date, or whether two dates are the same.   We
>> all know March 24th in London covers a different 24 hours than March 24th in
>> Hawaii but Date>>#= does not.
>>
>>
>>
>> I think whats needed are more descriptive selectors like
>>
>>
>> Date>>#isSameOnDateAs: aDateOrDateAndTime
>> Date>>#overlapsWithDate: aDate
>> DateAndTime>>#occursOnDate: aDate
>> DateAndTime>>#sameHMSButDifferentUTCIn: aTimeZoneKey
>> DateAndTime>>#sameUTCButDifferentHMSIn: aTimeZoneKey
>>
>> and change Date>>#= to #shouldNotImplement.
>>
>>
>> FWIW I also don't like #offset: as before you send it you know the timezone
>> and after you may let that knowledge be forgotten. Real offsets can change
>> as laws change.
>>
>>
>>
>> I think people are aware of this but if you have need for comparing dates &
>> times then you must use a library that accesses the regularly updated Olson
>> timezone database on your system and classes that respect time zones.  Time
>> zones are political, and legal definitions of offsets can change hours
>> before the DST transition dates & times.
>>
>>
>> I don't think it matters which default timezone you pick for the image if
>> you're not going to take them into account when doing comparisons.
>>
>>
>> Unfortunately there isn't a way to avoid this complexity until DST goes
>> away.
>>
>>
>> There's certainly flaws to how we currently do it and I think
>> TimeZoneDatabase and Chronos make good attempts to fix it.  I haven't looked
>> at Chalten but would guess its good too.
>>
>>
>>
>>
>>
>>
>>
>>
>> Sean P. DeNigris wrote
>>> I was bitten by this very annoying bug again. As most of us probably know
>>> due
>>> to the steady stream of confused ML posts in the past, the bug in summary
>>> is
>>> that we have an incomplete timezone implementation that doesn't properly
>>> take into account historical DST changes. This flares up without warning
>>> especially when DST toggles. I created a wiki page to document the
>>> situation: https://github.com/seandenigris/pharo/wiki/Time-Zone-Fiasco
>>>
>>> Here's an example blowup: at 11:59pm before DST changes, eval aDate :=
>>> '1/1/1901' asDate. Now, wait two minutes and at 12:01am eval self assert:
>>> '1/1/1901' asDate = aDate and… whammo, an exception! The "different"
>>> offsets
>>> render equal dates unequal depending on when the objects were created.
>>>
>>> The more I think about it, the more I think that we should just assume UTC
>>> for all Date[AndTime]s that don't explicitly specify an offset, rather
>>> than
>>> pretend to set an offset which is only sometimes correct. More advanced
>>> users can use one of the available libraries to get full timezone support.
>>> What do you think?
>>>
>>>
>>>
>>> -----
>>> Cheers,
>>> Sean
>>> --
>>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>>
>>
>>
>>
>>
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>>
> 

-- 
Esteban A. Maringolo

Reply via email to