On Sat, Mar 26, 2016 at 4:30 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
> On 25 Mar 2016, at 18:49, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
>
> On Fri, Mar 25, 2016 at 10:08 AM, Bert Freudenberg <bert at freudenbergs.de>
> wrote:
>>
>> On 25.03.2016, at 17:47, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>
>>
>> On Fri, Mar 25, 2016 at 9:23 AM, Bert Freudenberg <bert at 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.
>
>
> I wrote up the algorithm I propose; see
> http://forum.world.st/Time-millisecondClockValue-was-The-Trunk-Morphic-mt-1080-mcz-tt4877661.html#a4877918


It would be useful if the 'now' instance variable in VMClock
explicitly indicated in its name whether it was utcNow or localNow.
Even reading the man pages for gettimeofday() and clock_gettime() its
not clear to me which it is.  I can only guess that in the face of
changing timezones, its not a good idea to drift localNow, and better
to drift utcNow and add a constant timeZoneOffset.


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


Microsoft, Linux & OSX all seem to agree that "Local-Time" is
timezoned-wall-clock, and "System-Time" is utc-wall-clock. So maybe
this is a worthwhile convention to continue?

"The localtime() function converts the calendar time to broken-down
time representation, expressed relative to the user's specified
timezone."  [1]

"The system time is always kept in Coordinated Universal Time (UTC)
and converted in applications to local time as needed. Local time is
the actual time in your current time zone, taking into account
daylight saving time (DST). [2]

"GetLocalTime - This function retrieves the current local date and time." [3]

"GetSystemTime - This function retrieves the current system date and
time. The system time is expressed in UTC." [4]


cheers -ben

P.S. I also found [5] interesting

[1] https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/localtime.3.html
[2] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/chap-Configuring_the_Date_and_Time.html
[3] https://msdn.microsoft.com/en-us/library/ee487966.aspx
[4] https://msdn.microsoft.com/en-us/library/ee488017.aspx
[5] https://msdn.microsoft.com/en-us/library/windows/desktop/dn553408(v=vs.85).aspx