[squeak-dev] DateAndTime - offset just bit me

Eliot Miranda eliot.miranda at gmail.com
Tue Mar 14 15:29:07 UTC 2017


On Tue, Mar 14, 2017 at 8:26 AM, Chris Cunningham <cunningham.cb at gmail.com>
wrote:

> HI.
>
> On Tue, Mar 14, 2017 at 8:13 AM, Eliot Miranda <eliot.miranda at gmail.com>
> 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.
>>
>
> To be precise, some places change 4 times a year (double daylight
> savings); some never change.
>

Ah, good to know.  Can you point to examples of the former?


> If there was a way to know what the local rules were at image startup, it
> could schedule a process to kick off around the right time to check for
> changes - or it could completely disable that checking.  Most of the year
> checking for changes is always no needed (unless the image starts up in a
> different zone, at which time it should immediately get the right offset).
> I don't have an actual suggestion (yet) on how to know when to start
> scanning for changes more regularly.  Maybe it could scan in the high
> priority background every 10 minutes for an offset change?
>

Exactly.  Once a minute would likely have minimal overhead.  Once every
thirty minutes at 1 second past the minute would probably be more than
adequate.  But right now we're not doing this.  What do we have to do to
arrange that we do?

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170314/3fb45e59/attachment.html>


More information about the Squeak-dev mailing list