DateAndTime - offset just bit me

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
cbc
Reply | Threaded
Open this post in threaded view
|

DateAndTime - offset just bit me

cbc
Hi.

I routinely do a scan of various resources, and of the other properties is an 'install date'.  I like to save these as DateAndTime, which of course use offset to get the 'right' time.

Well, just this past weekend my locale went into daylight savings time, which means that my local offset changed.  Which also means that all of the dates that I read in (such as install date) that also changed to daylight time have had their offsets changed.

I daily do a diff to see what has changed, and all of the install dates have now been updated to a different offset, which causes a large amount of noise that I need to wade through to see if anything of interest actually changed.

This is frustrating. Here is what I see DateAndTime working currently:
1> For DateAndTime now, it get the current offset and applies it to the DateAndTime.  This is as accurate as we are going to get (i.e., as long as my current machine is accurate, this value will be accurate).  Nice.
2> For any other time, if you make a DateAndTime out of a string that has a offset specified, it accurately create the right DateAndTime.  Also nice.
3> For any other time that you make a DateAndTime out of a string that doesn't have the offset specified (such as database values and system timestamps from many utilities), you get the current off of your machine stamped.  Definitely not nice.  For instance:
    DateAndTime now "==> 2017-03-13T08:57:36.772086-07:00"
    '2017-03-10 00:00:00' asDateAndTime "==> 2017-03-10T00:00:00-07:00"
    (that last one should be -08:00 offset)

I'm trying to decide what to do about this.  

One option is to just keep the timestamps as strings - except they aren't always in the same format, so I can't compare them (which gets me roughly back to the same point).

Another is to install one of the better date/time packages that uses the Olson database to figure out what the current offset it, and have it deal with those issues automatically.  Except that feels like overkill for what I really want - a simple way to see if a date/time changed.

Another it to create a sibling class to DateAndTime that keeps the zone (but not offset) - say Pacific Time instead of Pacific Standard Time or Pacific Daylight Time.  And this would NOT include the offset.  This would allow for quick, accurate comparisions, and if (probably when) I need to compare to get hour differences, I could load one of the other tools to figure out what the offset it for each date/time and turn those into real, accurate DateAndTime instances for that compare.

So, does anyone else have these issues?  Is there a better option?

Thanks,
cbc


Reply | Threaded
Open this post in threaded view
|

Re: DateAndTime - offset just bit me

David T. Lewis
Hi Chris,

Yes there is a better option. If you don't mind being a test pilot, please
give this a try:

http://www.squeaksource.com/UTCDateAndTime/

The Olson database (TimeZoneDatabase on SqueakSource, originally written
by me) turns out to be mostly unnecessary once you have moved to the
UTCDateAndTime updates. But I would not discourage you from trying that as
well :-)

Dave

Try it in a test image, because there is no "uninstall" possible.

> Hi.
>
> I routinely do a scan of various resources, and of the other properties is
> an 'install date'.  I like to save these as DateAndTime, which of course
> use offset to get the 'right' time.
>
> Well, just this past weekend my locale went into daylight savings time,
> which means that my local offset changed.  Which also means that all of
> the
> dates that I read in (such as install date) that also changed to daylight
> time have had their offsets changed.
>
> I daily do a diff to see what has changed, and all of the install dates
> have now been updated to a different offset, which causes a large amount
> of
> noise that I need to wade through to see if anything of interest actually
> changed.
>
> This is frustrating. Here is what I see DateAndTime working currently:
> 1> For DateAndTime now, it get the current offset and applies it to the
> DateAndTime.  This is as accurate as we are going to get (i.e., as long as
> my current machine is accurate, this value will be accurate).  Nice.
> 2> For any other time, if you make a DateAndTime out of a string that has
> a
> offset specified, it accurately create the right DateAndTime.  Also nice.
> 3> For any other time that you make a DateAndTime out of a string that
> doesn't have the offset specified (such as database values and system
> timestamps from many utilities), you get the current off of your machine
> stamped.  Definitely not nice.  For instance:
>     DateAndTime now "==> 2017-03-13T08:57:36.772086-07:00"
>     '2017-03-10 00:00:00' asDateAndTime "==> 2017-03-10T00:00:00-07:00"
>     (that last one should be -08:00 offset)
>
> I'm trying to decide what to do about this.
>
> One option is to just keep the timestamps as strings - except they aren't
> always in the same format, so I can't compare them (which gets me roughly
> back to the same point).
>
> Another is to install one of the better date/time packages that uses the
> Olson database to figure out what the current offset it, and have it deal
> with those issues automatically.  Except that feels like overkill for what
> I really want - a simple way to see if a date/time changed.
>
> Another it to create a sibling class to DateAndTime that keeps the zone
> (but not offset) - say Pacific Time instead of Pacific Standard Time or
> Pacific Daylight Time.  And this would NOT include the offset.  This would
> allow for quick, accurate comparisions, and if (probably when) I need to
> compare to get hour differences, I could load one of the other tools to
> figure out what the offset it for each date/time and turn those into real,
> accurate DateAndTime instances for that compare.
>
> So, does anyone else have these issues?  Is there a better option?
>
> Thanks,
> cbc
>
>



Reply | Threaded
Open this post in threaded view
|

Re: DateAndTime - offset just bit me

Eliot Miranda-2
In reply to this post by cbc
Hi Chris,

On Mon, Mar 13, 2017 at 10:45 AM, Chris Cunningham <[hidden email]> wrote:
Hi.

I routinely do a scan of various resources, and of the other properties is an 'install date'.  I like to save these as DateAndTime, which of course use offset to get the 'right' time.

Well, just this past weekend my locale went into daylight savings time, which means that my local offset changed.  Which also means that all of the dates that I read in (such as install date) that also changed to daylight time have had their offsets changed.

I daily do a diff to see what has changed, and all of the install dates have now been updated to a different offset, which causes a large amount of noise that I need to wade through to see if anything of interest actually changed.

This is frustrating. Here is what I see DateAndTime working currently:
1> For DateAndTime now, it get the current offset and applies it to the DateAndTime.  This is as accurate as we are going to get (i.e., as long as my current machine is accurate, this value will be accurate).  Nice.
2> For any other time, if you make a DateAndTime out of a string that has a offset specified, it accurately create the right DateAndTime.  Also nice.
3> For any other time that you make a DateAndTime out of a string that doesn't have the offset specified (such as database values and system timestamps from many utilities), you get the current off of your machine stamped.  Definitely not nice.  For instance:
    DateAndTime now "==> 2017-03-13T08:57:36.772086-07:00"
    '2017-03-10 00:00:00' asDateAndTime "==> 2017-03-10T00:00:00-07:00"
    (that last one should be -08:00 offset)

I'm trying to decide what to do about this.  

One option is to just keep the timestamps as strings - except they aren't always in the same format, so I can't compare them (which gets me roughly back to the same point).

Another is to install one of the better date/time packages that uses the Olson database to figure out what the current offset it, and have it deal with those issues automatically.  Except that feels like overkill for what I really want - a simple way to see if a date/time changed.

Another it to create a sibling class to DateAndTime that keeps the zone (but not offset) - say Pacific Time instead of Pacific Standard Time or Pacific Daylight Time.  And this would NOT include the offset.  This would allow for quick, accurate comparisions, and if (probably when) I need to compare to get hour differences, I could load one of the other tools to figure out what the offset it for each date/time and turn those into real, accurate DateAndTime instances for that compare.

So, does anyone else have these issues?  Is there a better option?

What bit me today was that when the clocks went back the image, which I'd left running overnight, did not.  Consequent;y when it competed a timestamp it computed a value an hour out up until I quit and restarted the image.  The result was that the Slang Smalltalk-to-C translator refused to output any code because the timestamp of the source classes was an hour behind the timestamp of the generated source, so it thought that generated source had already been generated.

So the issue for me is that the time zone doesn't update when it should.  One solution would be to schedule a long-running process that would expire when the next timezone change is anticipated.  Another solution might be to have class side code in Delay  or Time periodically check (once an hour?) for the timezone.

Thanks,
cbc

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


Reply | Threaded
Open this post in threaded view
|

Re: DateAndTime - offset just bit me

Levente Uzonyi
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.

Levente

On Mon, 13 Mar 2017, Eliot Miranda wrote:

> Hi Chris,
> On Mon, Mar 13, 2017 at 10:45 AM, Chris Cunningham <[hidden email]> wrote:
>       Hi.
> I routinely do a scan of various resources, and of the other properties is an 'install date'.  I like to save these as DateAndTime, which of course use offset to get the 'right' time.
>
> Well, just this past weekend my locale went into daylight savings time, which means that my local offset changed.  Which also means that all of the dates that I read in (such as install date) that also
> changed to daylight time have had their offsets changed.
>
> I daily do a diff to see what has changed, and all of the install dates have now been updated to a different offset, which causes a large amount of noise that I need to wade through to see if anything
> of interest actually changed.
>
> This is frustrating. Here is what I see DateAndTime working currently:
> 1> For DateAndTime now, it get the current offset and applies it to the DateAndTime.  This is as accurate as we are going to get (i.e., as long as my current machine is accurate, this value will be
> accurate).  Nice.
> 2> For any other time, if you make a DateAndTime out of a string that has a offset specified, it accurately create the right DateAndTime.  Also nice.
> 3> For any other time that you make a DateAndTime out of a string that doesn't have the offset specified (such as database values and system timestamps from many utilities), you get the current off of
> your machine stamped.  Definitely not nice.  For instance:
>     DateAndTime now "==> 2017-03-13T08:57:36.772086-07:00"
>     '2017-03-10 00:00:00' asDateAndTime "==> 2017-03-10T00:00:00-07:00"
>     (that last one should be -08:00 offset)
>
> I'm trying to decide what to do about this.  
>
> One option is to just keep the timestamps as strings - except they aren't always in the same format, so I can't compare them (which gets me roughly back to the same point).
>
> Another is to install one of the better date/time packages that uses the Olson database to figure out what the current offset it, and have it deal with those issues automatically.  Except that feels
> like overkill for what I really want - a simple way to see if a date/time changed.
>
> Another it to create a sibling class to DateAndTime that keeps the zone (but not offset) - say Pacific Time instead of Pacific Standard Time or Pacific Daylight Time.  And this would NOT include the
> offset.  This would allow for quick, accurate comparisions, and if (probably when) I need to compare to get hour differences, I could load one of the other tools to figure out what the offset it for
> each date/time and turn those into real, accurate DateAndTime instances for that compare.
>
> So, does anyone else have these issues?  Is there a better option?
>
>
> What bit me today was that when the clocks went back the image, which I'd left running overnight, did not.  Consequent;y when it competed a timestamp it computed a value an hour out up until I quit and
> restarted the image.  The result was that the Slang Smalltalk-to-C translator refused to output any code because the timestamp of the source classes was an hour behind the timestamp of the generated source,
> so it thought that generated source had already been generated.
>
> So the issue for me is that the time zone doesn't update when it should.  One solution would be to schedule a long-running process that would expire when the next timezone change is anticipated.  Another
> solution might be to have class side code in Delay  or Time periodically check (once an hour?) for the timezone.
>
>       Thanks,
> cbc
>
>
> _,,,^..^,,,_
> best, Eliot
>
>

Reply | Threaded
Open this post in threaded view
|

Re: DateAndTime - offset just bit me

David T. Lewis
In reply to this post by Eliot Miranda-2
On Mon, Mar 13, 2017 at 08:11:49PM -0700, Eliot Miranda wrote:

> Hi Chris,
>
> On Mon, Mar 13, 2017 at 10:45 AM, Chris Cunningham <[hidden email]> wrote:
>
> >
> > So, does anyone else have these issues?  Is there a better option?
> >
>
> What bit me today was that when the clocks went back the image, which I'd
> left running overnight, did not.  Consequent;y when it competed a timestamp
> it computed a value an hour out up until I quit and restarted the image.
> The result was that the Slang Smalltalk-to-C translator refused to output
> any code because the timestamp of the source classes was an hour behind the
> timestamp of the generated source, so it thought that generated source had
> already been generated.
>
> So the issue for me is that the time zone doesn't update when it should.
> One solution would be to schedule a long-running process that would expire
> when the next timezone change is anticipated.  Another solution might be to
> have class side code in Delay  or Time periodically check (once an hour?)
> for the timezone.

The "long running process" idea is how I did it 18 years ago in the
TimeZoneDatabase package. I'm not proud of it, but it did work, sort of ;-)

For the situation today, you have just exactly described the rationale for
this primitive:

  primitiveUtcWithOffset
        "Answer an array with UTC microseconds since the Posix epoch and the
        current seconds offset from GMT in the local time zone. An empty two
        element array (or any object with two or more slots) may be supplied
        as a parameter.
        This is a named (not numbered) primitive in the null module (ie the VM)"

as well as for using this primitive when creating new instances of DateAndTime
to represent the current time.

This can work with our current Chronology implementation, but it is much
easier to understand when the implementation directly reflects it, hence
the UTCDateAndTime updates.

Specifically with respect to "DateAndTime now" across a daylight savings
transition: Assuming that your operating system does a good job of reporting
time with local offset (which is probably does), then the magnitude of the
DateAndTime (the utcMicroseconds ivar) will not jump forward or back at the
DST transition, and any time stamp based on that magnitude will behave
in reasonable ways.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: DateAndTime - offset just bit me

Eliot Miranda-2
In reply to this post by Levente Uzonyi
Hi Levente,

On Tue, Mar 14, 2017 at 2:41 AM, Levente Uzonyi <[hidden email]> 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.
 

Levente


On Mon, 13 Mar 2017, Eliot Miranda wrote:

Hi Chris,
On Mon, Mar 13, 2017 at 10:45 AM, Chris Cunningham <[hidden email]> wrote:
      Hi.
I routinely do a scan of various resources, and of the other properties is an 'install date'.  I like to save these as DateAndTime, which of course use offset to get the 'right' time.

Well, just this past weekend my locale went into daylight savings time, which means that my local offset changed.  Which also means that all of the dates that I read in (such as install date) that also
changed to daylight time have had their offsets changed.

I daily do a diff to see what has changed, and all of the install dates have now been updated to a different offset, which causes a large amount of noise that I need to wade through to see if anything
of interest actually changed.

This is frustrating. Here is what I see DateAndTime working currently:
1> For DateAndTime now, it get the current offset and applies it to the DateAndTime.  This is as accurate as we are going to get (i.e., as long as my current machine is accurate, this value will be
accurate).  Nice.
2> For any other time, if you make a DateAndTime out of a string that has a offset specified, it accurately create the right DateAndTime.  Also nice.
3> For any other time that you make a DateAndTime out of a string that doesn't have the offset specified (such as database values and system timestamps from many utilities), you get the current off of
your machine stamped.  Definitely not nice.  For instance:
    DateAndTime now "==> 2017-03-13T08:57:36.772086-07:00"
    '2017-03-10 00:00:00' asDateAndTime "==> 2017-03-10T00:00:00-07:00"
    (that last one should be -08:00 offset)

I'm trying to decide what to do about this.  

One option is to just keep the timestamps as strings - except they aren't always in the same format, so I can't compare them (which gets me roughly back to the same point).

Another is to install one of the better date/time packages that uses the Olson database to figure out what the current offset it, and have it deal with those issues automatically.  Except that feels
like overkill for what I really want - a simple way to see if a date/time changed.

Another it to create a sibling class to DateAndTime that keeps the zone (but not offset) - say Pacific Time instead of Pacific Standard Time or Pacific Daylight Time.  And this would NOT include the
offset.  This would allow for quick, accurate comparisions, and if (probably when) I need to compare to get hour differences, I could load one of the other tools to figure out what the offset it for
each date/time and turn those into real, accurate DateAndTime instances for that compare.

So, does anyone else have these issues?  Is there a better option?


What bit me today was that when the clocks went back the image, which I'd left running overnight, did not.  Consequent;y when it competed a timestamp it computed a value an hour out up until I quit and
restarted the image.  The result was that the Slang Smalltalk-to-C translator refused to output any code because the timestamp of the source classes was an hour behind the timestamp of the generated source,
so it thought that generated source had already been generated.

So the issue for me is that the time zone doesn't update when it should.  One solution would be to schedule a long-running process that would expire when the next timezone change is anticipated.  Another
solution might be to have class side code in Delay  or Time periodically check (once an hour?) for the timezone.

      Thanks,
cbc

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

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


Reply | Threaded
Open this post in threaded view
|

Re: DateAndTime - offset just bit me

Eliot Miranda-2
In reply to this post by David T. Lewis
Hi David,

On Tue, Mar 14, 2017 at 5:52 AM, David T. Lewis <[hidden email]> wrote:
On Mon, Mar 13, 2017 at 08:11:49PM -0700, Eliot Miranda wrote:
> Hi Chris,
>
> On Mon, Mar 13, 2017 at 10:45 AM, Chris Cunningham <[hidden email]> wrote:
>
> >
> > So, does anyone else have these issues?  Is there a better option?
> >
>
> What bit me today was that when the clocks went back the image, which I'd
> left running overnight, did not.  Consequent;y when it competed a timestamp
> it computed a value an hour out up until I quit and restarted the image.
> The result was that the Slang Smalltalk-to-C translator refused to output
> any code because the timestamp of the source classes was an hour behind the
> timestamp of the generated source, so it thought that generated source had
> already been generated.
>
> So the issue for me is that the time zone doesn't update when it should.
> One solution would be to schedule a long-running process that would expire
> when the next timezone change is anticipated.  Another solution might be to
> have class side code in Delay  or Time periodically check (once an hour?)
> for the timezone.

The "long running process" idea is how I did it 18 years ago in the
TimeZoneDatabase package. I'm not proud of it, but it did work, sort of ;-)

For the situation today, you have just exactly described the rationale for
this primitive:

  primitiveUtcWithOffset
        "Answer an array with UTC microseconds since the Posix epoch and the
        current seconds offset from GMT in the local time zone. An empty two
        element array (or any object with two or more slots) may be supplied
        as a parameter.
        This is a named (not numbered) primitive in the null module (ie the VM)"

as well as for using this primitive when creating new instances of DateAndTime
to represent the current time.

This can work with our current Chronology implementation, but it is much
easier to understand when the implementation directly reflects it, hence
the UTCDateAndTime updates.

Specifically with respect to "DateAndTime now" across a daylight savings
transition: Assuming that your operating system does a good job of reporting
time with local offset (which is probably does), then the magnitude of the
DateAndTime (the utcMicroseconds ivar) will not jump forward or back at the
DST transition, and any time stamp based on that magnitude will behave
in reasonable ways.

So we have all the necessary machinery, but my experience yesterday reflects the fact that we don't yet use it.  o what's required to start using it?
 

Dave





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


cbc
Reply | Threaded
Open this post in threaded view
|

Re: DateAndTime - offset just bit me

cbc
In reply to this post by Eliot Miranda-2
HI.

On Tue, Mar 14, 2017 at 8:13 AM, Eliot Miranda <[hidden email]> wrote:
Hi Levente,

On Tue, Mar 14, 2017 at 2:41 AM, Levente Uzonyi <[hidden email]> 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.
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?

-cbc


Reply | Threaded
Open this post in threaded view
|

Re: DateAndTime - offset just bit me

Eliot Miranda-2


On Tue, Mar 14, 2017 at 8:26 AM, Chris Cunningham <[hidden email]> wrote:
HI.

On Tue, Mar 14, 2017 at 8:13 AM, Eliot Miranda <[hidden email]> wrote:
Hi Levente,

On Tue, Mar 14, 2017 at 2:41 AM, Levente Uzonyi <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: DateAndTime - offset just bit me

Levente Uzonyi
On Tue, 14 Mar 2017, Eliot Miranda wrote:

>
>
> On Tue, Mar 14, 2017 at 8:26 AM, Chris Cunningham <[hidden email]> wrote:
>       HI.
>
>       On Tue, Mar 14, 2017 at 8:13 AM, Eliot Miranda <[hidden email]> wrote:
>             Hi Levente,
>             On Tue, Mar 14, 2017 at 2:41 AM, Levente Uzonyi <[hidden email]> 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
>
>

cbc
Reply | Threaded
Open this post in threaded view
|

Re: DateAndTime - offset just bit me

cbc
In reply to this post by Eliot Miranda-2


On Tue, Mar 14, 2017 at 8:29 AM, Eliot Miranda <[hidden email]> wrote:


On Tue, Mar 14, 2017 at 8:26 AM, Chris Cunningham <[hidden email]> wrote:
HI.

On Tue, Mar 14, 2017 at 8:13 AM, Eliot Miranda <[hidden email]> wrote:
Hi Levente,

On Tue, Mar 14, 2017 at 2:41 AM, Levente Uzonyi <[hidden email]> 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?

Hmm.  No, I can't.  I could have sworn it happened, but apparently I gathered the knowledge many years ago when it had happened (recently-ish) and there was a move to try and adopt it at various points.  That said, it doesn't look like it is actually being used that I can find, so feel free to ignore this for going forward.

-cbc


Reply | Threaded
Open this post in threaded view
|

Re: DateAndTime - offset just bit me

David T. Lewis
In reply to this post by Eliot Miranda-2
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 <[hidden email]>
> 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