<div dir="ltr">Hi Levente,<div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 14, 2017 at 2:41 AM, Levente Uzonyi <span dir="ltr"><<a href="mailto:leves@caesar.elte.hu" target="_blank">leves@caesar.elte.hu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Eliot,<br>
<br>
I pointed out earlier that the time zone doesn't update in primitive 241 or primitiveUtcWithOffset when DST changes happen.<br>
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.<br>
It would be nice if the other two primitives worked correctly.</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="gmail-HOEnZb"><font color="#888888">
<br>
Levente</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
<br>
On Mon, 13 Mar 2017, Eliot Miranda wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hi Chris,<br>
On Mon, Mar 13, 2017 at 10:45 AM, Chris Cunningham <<a href="mailto:cunningham.cb@gmail.com" target="_blank">cunningham.cb@gmail.com</a>> wrote:<br>
      Hi.<br>
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.<br>
<br>
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<br>
changed to daylight time have had their offsets changed.<br>
<br>
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<br>
of interest actually changed.<br>
<br>
This is frustrating. Here is what I see DateAndTime working currently:<br>
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<br>
accurate).  Nice.<br>
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.<br>
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<br>
your machine stamped.  Definitely not nice.  For instance:<br>
    DateAndTime now "==> 2017-03-13T08:57:36.772086-07:<wbr>00"<br>
    '2017-03-10 00:00:00' asDateAndTime "==> 2017-03-10T00:00:00-07:00"<br>
    (that last one should be -08:00 offset)<br>
<br>
I'm trying to decide what to do about this.  <br>
<br>
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).<br>
<br>
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<br>
like overkill for what I really want - a simple way to see if a date/time changed.<br>
<br>
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<br>
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<br>
each date/time and turn those into real, accurate DateAndTime instances for that compare.<br>
<br>
So, does anyone else have these issues?  Is there a better option?<br>
<br>
<br>
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<br>
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,<br>
so it thought that generated source had already been generated.<br>
<br>
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<br>
solution might be to have class side code in Delay  or Time periodically check (once an hour?) for the timezone.<br>
<br>
      Thanks,<br>
cbc<br>
<br>
_,,,^..^,,,_<br>
best, Eliot<br></blockquote></div></div></blockquote></div><br><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>