What is a field based date and  time?

On Tue, Apr 10, 2018 at 1:32 PM, 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.
>
> 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