> On 10 Apr 2018, at 13:32, Esteban A. Maringolo <emaring...@gmail.com> wrote:
> 
> 
> 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.

Like Sean said elsewhere, the exist (much) better add-on frameworks, if you 
choose to use them, but they are optional.

Right now, we are discussing what should be in the image by default.

The current system is not bad at all, it just has deficiencies that could be 
improved upon.

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

I am not so sure that is a good example. 

> 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