[squeak-dev] DateAndTime - offset just bit me

Eliot Miranda eliot.miranda at gmail.com
Tue Mar 14 15:14:17 UTC 2017

Hi David,

On Tue, Mar 14, 2017 at 5:52 AM, David T. Lewis <lewis at mail.msen.com> 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 <
> 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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170314/fae79322/attachment.html>

More information about the Squeak-dev mailing list