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 <cunningham.cb at gmail.com> 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