<div dir="ltr">Hi David,<div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 14, 2017 at 5:52 AM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Mar 13, 2017 at 08:11:49PM -0700, Eliot Miranda wrote:<br>
> Hi Chris,<br>
><br>
> On Mon, Mar 13, 2017 at 10:45 AM, Chris Cunningham <<a href="mailto:cunningham.cb@gmail.com">cunningham.cb@gmail.com</a>> wrote:<br>
><br>
> ><br>
</span><span class="">> > 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<br>
> left running overnight, did not.  Consequent;y when it competed a timestamp<br>
> it computed a value an hour out up until I quit and restarted the image.<br>
> The result was that the Slang Smalltalk-to-C translator refused to output<br>
> any code because the timestamp of the source classes was an hour behind the<br>
> timestamp of the generated source, so it thought that generated source had<br>
> already been generated.<br>
><br>
> So the issue for me is that the time zone doesn't update when it should.<br>
> One solution would be to schedule a long-running process that would expire<br>
> when the next timezone change is anticipated.  Another solution might be to<br>
> have class side code in Delay  or Time periodically check (once an hour?)<br>
> for the timezone.<br>
<br>
</span>The "long running process" idea is how I did it 18 years ago in the<br>
TimeZoneDatabase package. I'm not proud of it, but it did work, sort of ;-)<br>
<br>
For the situation today, you have just exactly described the rationale for<br>
this primitive:<br>
<br>
  primitiveUtcWithOffset<br>
        "Answer an array with UTC microseconds since the Posix epoch and the<br>
        current seconds offset from GMT in the local time zone. An empty two<br>
        element array (or any object with two or more slots) may be supplied<br>
        as a parameter.<br>
        This is a named (not numbered) primitive in the null module (ie the VM)"<br>
<br>
as well as for using this primitive when creating new instances of DateAndTime<br>
to represent the current time.<br>
<br>
This can work with our current Chronology implementation, but it is much<br>
easier to understand when the implementation directly reflects it, hence<br>
the UTCDateAndTime updates.<br>
<br>
Specifically with respect to "DateAndTime now" across a daylight savings<br>
transition: Assuming that your operating system does a good job of reporting<br>
time with local offset (which is probably does), then the magnitude of the<br>
DateAndTime (the utcMicroseconds ivar) will not jump forward or back at the<br>
DST transition, and any time stamp based on that magnitude will behave<br>
in reasonable ways.<br></blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Dave<br>
<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="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>