`cctz::local_time_zone` returns UTC on windows

[vspinu]

I have recently integrated CCTZ into R package lubridate. So far everything worked as expected, except for the local timezone on windows. cctz::local_time_zone() returns UTC on that platform.

R itself goes through quite some pain to get the tzone on Windows. I wonder if something like that is within the scope of CCTZ.

[devjgm]

On Fri, Oct 6, 2017 at 9:10 AM, Vitalie Spinu ***@***.***> wrote: I have recently integrated CCTZ into R package lubridate <https://github.com/tidyverse/lubridate/>. So far everything worked as expected, except for the local timezone on windows. cctz::local_time_zone() <https://github.com/hadley/lubridate/blob/master/src/update.cpp#L29> returns UTC on that platform.

UTC is the fallback if cctz can't find any other reasonable local time zone. Today CCTZ looks for the local timezone by checking environment variables. So setting TZ=Foo/Bar should make cctz::local_time_zone() work, even on windows. But now I see that Windows has a GetTimeZoneInformation() <https://msdn.microsoft.com/en-us/library/windows/desktop/ms724421(v=vs.85).aspx> function, and that'd probably be a better thing to use. The ideal solution would be to also add a Windows-specific subclass of the cctz::TimeZoneIf interface, which would look up the time-zone data in the Windows registry, or wherever that data comes from on Windows. Coping the TimeZoneLibC <https://github.com/google/cctz/blob/master/src/time_zone_libc.h> class would be a good place to start. The reason we haven't done this already is because we don't have any Windows dev machines nor the experience to hack it together. We're hoping an experienced Windows developer might be interested in contributing this support to CCTZ :-)

R itself goes through quite some pain <https://github.com/SurajGupta/r-source/blob/master/src/extra/tzone/registryTZ.c> to get the tzone on Windows. I wonder if something like that is within the scope of CCTZ.

Yes. See comments above.

…

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#53>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJAo20CN8iGfWhDoT1jqq9i3Aj0hOGvlks5spibWgaJpZM4PwdVf> .

[devbww]

Hi Vitalie,

I don't think we would want to try to maintain anything like TZtable[] from the referenced R code.

On the Windows machine you must have installed the zoneinfo files somewhere (and set $TZDIR to that location), yes? You can affect what cctz::local_time_zone() will return by copying the local zoneinfo file to a file named "localtime" within $TZDIR. Alternatively, you can set $TZ to the name of the local zoneinfo file.

Bradley

[vspinu]

Thanks for the fast response!

We're hoping an experienced Windows developer

I am not the one :). I barely figured out the above in virtual box myself.

UTC is the fallback if cctz

This is an unfortunate design choice. There is no way for me to know if UTC was really my user's choice or CCTZ pulled it out of the thin air.

[vspinu]

On the Windows machine you must have installed the zoneinfo files somewhere (and set $TZDIR to that location), yes?

Not really. I develop an R package on top of CCTZ, so it's up to my end user to set TZ or TZDIR. I don't control that.

You can affect what cctz::local_time_zone() will return by copying the local zoneinfo file to a file named "localtime" within $TZDIR.

R indeed has a copy of zoneinfo but that localtime is not up-todate. Window user can change his/her timezone anytime and it won't be reflected in the localtime file. I guess this is precisely why R relies on GetTimeZoneInformation and has that rzregistry internally.

[devjgm]

On Fri, Oct 6, 2017 at 9:45 AM, Vitalie Spinu ***@***.***> wrote: Thanks for fast response! We're hoping an experienced Windows developer I am not the one :). I barely figured out the above in virtual box myself. UTC is the fallback if cctz This is an unfortunate design choice. There is no way for me to know if UTC was really an user's choice or CCTZ pulled it out of the thin air.

It's a pretty common design choice. I'd be curious to know what your code would do differently if it could tell the difference between a UTC "fallback" vs the local time zone actually being set to UTC.

…

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <#53 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJAo247t__dHB5FSRFNqoiv6svMpa19Gks5spi7qgaJpZM4PwdVf> .

[devbww]

everything worked as expected, except for the local timezone on windows. cctz::local_time_zone() returns UTC on that platform.

it's up to my end user to set TZ or TZDIR. I don't control that.

Are you saying that TZ and TZDIR were set to something valid (and not UTC) but cctz::local_time_zone() still returned UTC?

[vspinu]

I'd be curious to know what your code would do differently

I would recur to more expensive lookup mechanisms available to me. In my case I can call R's own Sys.timezone which is full of system calls and has different implementations depending on OS. That R level call would be rather expensive, but at least it's sure to return something valid.

It's a pretty common design choice.

Adding an unknown timezone and the default_tz argument to local_time_zone might be an easy fix.

Are you saying that TZ and TZDIR were set to something valid (and not UTC) but cctz::local_time_zone() still returned UTC?

TZDIR is set (R ships with its own zoneinfo on Windows), but TZ is not.

> Sys.getenv("TZDIR")
[1] "C:/PROGRA~1/R/R-34~1.1/share/zoneinfo"
> Sys.getenv("TZ")
[1] ""

What I meant is that even if there is zoneinfo on windows somewhere, windoze won't bother to update the default timezone there. So that info is useless. But TZDIR seems to be irrelevant anyway. AFAICS local_time_zone doesn't rely on TZDIR at all, it only checks for $TZ, /etc/localtime and $LOCALTIME.

[devbww]

AFAICS local_time_zone doesn't rely on TZDIR at all, it only checks for $TZ, /etc/localtime and $LOCALTIME.

On Windows it looks for $TZDIR/localtime.

[yukawa]

But now I see that Windows has a GetTimeZoneInformation() https://msdn.microsoft.com/en-us/library/windows/desktop/ms724421(v=vs.85).aspx function, and that'd probably be a better thing to use. The ideal solution would be to also add a Windows-specific subclass of the cctz::TimeZoneIf interface, which would look up the time-zone data in the Windows registry, or wherever that data comes from on Windows.

Just fyi, I recently had a time to actually implement cctz::TimeZoneIf with Windows registry. For those who are interested in, here is the discussion thread I opened.

• cctz::TimeZoneIf implementation that is compatible with Windows time APIs #328

A draft PR is also available here.

• Implement TimeZoneIf with Windows Registry #327