Hello Avik. That is fact. As you knowl, the local offset often is obtainable through calls to C or C++ Standard libraries. Unfortunately OSs vary greatly in the care and feeding of flexible and accurate support for time.
Some OSs may need us to provide portable run-alikes (or not). Is Julia distributed with unexposed but exposable low level time functions? I copied stuff from Libc.jl and have a variant that (should work) just as it has. There are a few functions where adding `true` as the final argument for a call will change the time being processed and UT or UTC dependant information is obtained. I prefer not using them directly -- they C functions are are methodolgical fragments by design. On Monday, July 13, 2015 at 8:18:16 PM UTC-4, Avik Sengupta wrote: > > now() - now(Dates.UTC) does not actually return the correct current local > offset, since the two now() invocations happen a few milliseconds apart, > and thus do not denote the exact same time. Hence their difference then is > not the exact local difference. So unfortunately, as a hack, it does not > quite seem to work. > > For example, with GMT-1, on a mac: > > *julia> **now() - now(Dates.UTC)* > > *3599430 milliseconds* > > > *julia> **Dates.Second(div(Dates.value(now() - now(Dates.UTC)),1000))* > > *3599 seconds* > > On Friday, 10 July 2015 17:49:45 UTC+1, Jacob Quinn wrote: >> >> >> On Fri, Jul 10, 2015 at 8:11 AM, Tom Breloff <[email protected]> wrote: >> >>> as >> >> >> Tom, >> >> Yes, the method I proposed won't work retroactively since the method for >> getting the current local offset from GMT is `now() - now(Dates.UTC)`. If >> you were to run that every second crossing over the daylight savings >> moment, you'd see that it correctly adjusts for daylight savings, but it's >> only going to give you the *current* offset from GMT. Something more >> elaborate will require tapping into the tzinfo database (which TimeZones.jl >> will do). >> >> -Jacob >> >
