On Tue, 14 Mar 2017, Eliot Miranda wrote:

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

Instead of spawning a process for this, the primitive could do the heavy 
lifting by saving its last generated value in a static variable (0 on 
startup). On each primitive call it would compare the static variable's 
value with the current timestamp. If they are in a different minute (they 
are not equal / 60000000), half hour (not equal / 1800000000), etc, then 
update the time zone information.
As an optimization, the program could store the value divided by the 
length of the interval to save a divison per primitive call. :)

This would
- be a simple change local to the primitive itself
- have minimal overhead
- require no image side heavy lifting
- work even when the physical machine is suspended/hibernated in 
one time zone and is awaken in another while the VM is running on it.

Levente

> 
> _,,,^..^,,,_
> best, Eliot
> 
>