regebro / tzlocal

A Python module that tries to figure out what your local timezone is

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Win10 with turned off dst always run into offset error

muffmolch opened this issue · comments

I am using APScheduler and this uses tzlocal.
My flask server runs on a Windows10-PC with turned off day saving time options (means no extra offset in summer here in germany). But this results in errors in:

from tzlocal import get_localzone
tz = get_localzone()

How do I solve this issue?

Best regards
Sören

callstack:

File "e:\ProgalSrc2\IM_Testrepo\IMServer\venv\lib\site-packages\tzlocal\win32.py", line 95, in get_localzone
    utils.assert_tz_offset(_cache_tz)
  File "e:\ProgalSrc2\IM_Testrepo\IMServer\venv\lib\site-packages\tzlocal\utils.py", line 46, in assert_tz_offset
    raise ValueError(msg)
ValueError: Timezone offset does not match system offset: 7200 != 3600. Please, check your config files.

Regarding your comment
#79 (comment)

The machine has to run with this option. Thus, deactivating this options is no option :-(
But you meant You can get rid of the error by setting a TZ environment variable so it matches your incorrect setting, but it's honestly better to configure your computer correctly.

Can you give an example? I tried a lot, but nothing works.

Well, tzlocal is attempting to find the name of your timezone, figures out that should be Europe/Berlin, checks if that's correct, and figures out that in fact, it's not, and fails.

If your computer should always be one hour ahead of GMT, your best bet is to configure it to use "W. Central Africa Standard Time" as the Windows timezone, as that is one our ahead of GMT and doesn't use DST.

That should fix it.

Out of curiosity, WHY does it need to be one hour ahead of GMT regardless of DST?

This restrictions comes from the galvanic steering server that also runs on that server that doesn’t want to handle time holes :-) but nevertheless my flask server usually uses timezones in a correct way. But in this case the APScheduler uses your package inside, but I figured out that I can configure UTC timezone for that package. Thus that should fix the problem for the moment. But besides it would be nice if your lib respects deactivated dst in some way. It‘s an official configuration flag in Windows ... thus it would be great.

Hmm, I have to think about if that's possible.

Let me know if you need any help.

I've added support for this in 4.0, although not all timezones can be converted to Etc/GMT-X, so then it raises an error.