Hi Sven,

On Tue, Apr 10, 2018 at 7:33 AM, Sven Van Caekenberghe <s...@stfx.eu> wrote:

>
>
> > On 10 Apr 2018, at 16:13, Stephane Ducasse <stepharo.s...@gmail.com>
> wrote:
> >
> > What is a field based date and  time?
>
> This is more of an implementation choice but it has probably influence on
> the API as well.
>
> Field based date/time/datetime objects are like the naive implementation
> where each element that we talk about as humans has its own instance
> variable. You would store hours, minutes, seconds, nanosecond separately,
> as well as year, month, day.
>
> This is not as efficient as the current implementations, where time is
> typically stored as seconds and nanoseconds, and dates as a single julian
> day number.
>
> Still, these are implementation choices. For example, the split between
> seconds and nanoseconds is a bit artificial as well (it is so that both
> remain SmallIntegers in 32-bit), while in 64-bit this decision could be
> revised.
>

Note that the VM provides times as either 64-bit LargePositiveInteger
microseconds from 1901 (32-bits) or 61-bit positive SmallInteger
microseconds from 1901 (64-bits), in either UTC or the current time zone.

This gives us the following fit-for-purpose limits:

DateAndTime fromSeconds: 1 << 64 - 1 // 1000000 586455-01-18T08:01:49-07:00
DateAndTime fromSeconds: SmallInteger maxVal // 1000000
38435-08-17T21:30:06-07:00

Choosing 64-bit nanoseconds doesn't work nearly as well; we run out of bits
in 586 years.

I don't buy the performance issue of keeping things as SmallIntegers.
There is good 64-bit positive integer support in all the 32-bit VMs (e.g.
in the interpreter, inlined #+. #- et al all work on a 64-bit integer
range).  If Pharo does decide to change the internal representation then I
suggest that it uses the same representation as the VM.


> > 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
> >>
> >
>
>
>


-- 
_,,,^..^,,,_
best, Eliot

Reply via email to