On Sat, Mar 26, 2016 at 4:30 AM, Bert Freudenberg bert@freudenbergs.de wrote:
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.
I wrote up the algorithm I propose; see http://forum.world.st/Time-millisecondClockValue-was-The-Trunk-Morphic-mt-10...
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/ManPa... [2] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm... [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).a...