[squeak-dev] The Inbox: Kernel-cmm.669.mcz

Enrico Spinielli enrico.spinielli at googlemail.com
Mon Feb 6 20:55:42 UTC 2012


For leap seconds and how they are (mis)handled by the different OSs/distros
have a look at http://queue.acm.org/detail.cfm?id=1967009
On Feb 6, 2012 3:16 PM, "David T. Lewis" <lewis at mail.msen.com> wrote:

> On Mon, Feb 06, 2012 at 02:59:03PM +0100, Nicolas Cellier wrote:
> > 2012/2/6 David T. Lewis <lewis at mail.msen.com>:
> > >
> > > This still leaves us with the problem of converting from local time to
> UTC
> > > in the image, which is problematic during a daylight savings time
> transition
> > > (two values of the UTC seconds clock map to the same local seconds
> clock
> > > value, which one is correct?). It is better to use UTC because
> translating
> > > from UTC to local seconds is unambiguous.
> > >
> >
> > No, if the primitive also fill the localOffset, then you'll get twice
> > the same wallClockTime, but with a different localOffset.
> > In this case, conversion to UTC is trivial.
>
> Apologies, you are right of course.
>
> > > I think it is best to leave the complexity of translating to julian
> > > day, seconds, etc on the image side rather that put it in the VM,
> unless
> > > there is a measurable performance advantage to putting it in the VM.
> > >
> >
> > I don't know. The julianDayNumber sounds like assembler to me ;)
> >
> >       p := (monthIndex - 14) quo: 12.
> >       q := year + 4800 + p.
> >       r := monthIndex - 2 - (12 * p).
> >       s := (year + 4900 + p) quo: 100.
> >
> >       julianDayNumber :=
> >               ( (1461 * q) quo: 4 ) +
> >                       ( (367 * r) quo: 12 ) -
> >                               ( (3 * s) quo: 4 ) +
> >                                       ( day - 32075 ).
> >
> > Which date would overflow? Not that soon I guess.
> >
> > Also, I'm not sure that duplicating the time zone and DST handling in
> > the image is a good idea.
> > What advantage over OS would this provide?
>
> If you do it in the image you can get it done right now, and if you
> make a mistake you can fix it. If you do it in the VM, you will wait
> for everyone involved to come to agreement, implement the code, and
> distribute supported VMs.
>
> As far as time zone and DST handling, you cannot realistically do
> this in the VM except for the specific case of reporting the current
> time, which involves nothing more than reporting the offset from UTC
> in the current time zone at the current time. If the platform is
> not able to provide this support, then you just report an offset
> of zero.
>
> Dave
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120206/55884ff6/attachment.htm


More information about the Squeak-dev mailing list