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 |
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 > > |
In reply to this post by cbc
Hi Chris,
On Mon, Mar 13, 2017 at 10:45 AM, Chris Cunningham <[hidden email]> wrote:
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.
_,,,^..^,,,_ best, Eliot |
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 > > |
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 |
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, 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.
_,,,^..^,,,_ best, Eliot |
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: 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?
_,,,^..^,,,_ best, Eliot |
In reply to this post by Eliot Miranda-2
HI.
On Tue, Mar 14, 2017 at 8:13 AM, Eliot Miranda <[hidden email]> wrote:
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 |
On Tue, Mar 14, 2017 at 8:26 AM, Chris Cunningham <[hidden email]> wrote:
Ah, good to know. Can you point to examples of the former?
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 |
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? 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 > > |
In reply to this post by Eliot Miranda-2
On Tue, Mar 14, 2017 at 8:29 AM, Eliot Miranda <[hidden email]> wrote:
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 |
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 |
Free forum by Nabble | Edit this page |