On 25 Mar 2016, at 18:49, Eliot Miranda <eliot.miranda@gmail.com> wrote:



On Fri, Mar 25, 2016 at 10:08 AM, Bert Freudenberg <bert@freudenbergs.de> wrote:
On 25.03.2016, at 17:47, Eliot Miranda <eliot.miranda@gmail.com> wrote:

On Fri, Mar 25, 2016 at 9:23 AM, Bert Freudenberg <bert@freudenbergs.de> wrote:
Well, it’s okay to cheat as long as you won’t get caught (says DI).

Simply “once a second” is not good enough if we check the time 0.5 seconds after DST switch.

If “once a second” was implemented as “once every wall-clock second”, IMHO that would be fine. So the test would have to be something like

        (prevUsecs // 1000000) ~= (nowUsecs // 1000000) ifTrue: [self updateOffsetFromUTC]

Right?

Excellent point.  So the drift algorithm to provide an accurate clock can be extended to check the time zone whenever the new time is at a different second to the previous value.

Drifting makes this way more complicated I’d think … unless there is an OS function to convert the drifted UTC time into local? IF the VM time and system time differ, you can’t just ask the OS for the “now” local time.


It's not that complicated and extending it is straight-forward, given that the algorithm already maintains the last time computed.  When I've time I'll post a revision.

_,,,^..^,,,_
best, Eliot


Terminology confusion. In your post "local time" means "wall clock utc". I meant "time in local time zone".

But I see that there is indeed an OS function to convert a given UTC time to one in the local time zone. So yes, that sounds like a plan.

- Bert -