[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
|