[squeak-dev] DateAndTime - offset just bit me

David T. Lewis lewis at mail.msen.com
Wed Mar 15 03:13:02 UTC 2017


On Tue, Mar 14, 2017 at 08:13:08AM -0700, Eliot Miranda wrote:
> Hi Levente,
> 
> On Tue, Mar 14, 2017 at 2:41 AM, Levente Uzonyi <leves at caesar.elte.hu>
> wrote:
> 
> > Hi Eliot,
> >
> > I pointed out earlier that the time zone doesn't update in primitive 241
> > or primitiveUtcWithOffset when DST changes happen.
> > However, it does change in LocalePlugin's primitiveTimezoneOffset, which
> > is what we use as a workaround to create correct DateAndTime instances in
> > one of our projects.
> > It would be nice if the other two primitives worked correctly.
> 
> 
> Sure, but the point is that we don't want the normal time access primitive
> to update the timezone in 241 because that adds overhead to every
> invocation that pays off only twice a year.  As David points out
> primitiveUtcWithOffset /does/ update the timezone.  So what's needed is a
> way to arrange that primitiveUtcWithOffset is invoked often enough to
> update the timezone, but infrequently enough not to cost a lot.
> 

Hi Eliot,

On 64 bit Spur, using #primitiveUtcWithOffset with UTCDateAndTime:

  Time millisecondsToRun: [100000000 timesRepeat: [DateAndTime now]]. ==> 10468

And using the traditional DateAndTime:

  Time millisecondsToRun: [100000000 timesRepeat: [DateAndTime now]]. ==> 27478

Whatever overhead is involved in the direct use of #primitiveUtcWithOffset
is more than regained by the overall efficiency of the simpler time/offset
representation.

So from a performance point of view, I would not lose a lot of sleep worrying
about how to optimize this further in the primitives.

Levente is right that only LocalPlugin provides the time zone correctly, and
the time zone does not get updated in the image with the other primitives. But
there is no real need to be concerned about this if DateAndTime instances are
being created properly in the first place (which, as you noticed last weekend,
is not currently the case).

Dave



More information about the Squeak-dev mailing list