Closed morpheus65535 closed 5 years ago
Oh, wait, this is Windows, I didn't even connect that until now, since we had the same problem on Unix, but that was a different reason.
Could this be that the computer somehow didn't automatically switch from DST?
It does switch to DST without an issue. Time is good in any other program.
Very strange. What is your Windows Timezone? "Pacific SA Standard Time"?
You can reproduce using "(UTC-04:00) Santiago".
That is indeed the display name for "Pacific SA Standard Time", I'll try it out.
Yes I've just check with tzutil /g
and you are right.
It works fine for me, so it's not the timezone itself that has a problem. It's possible that the Windows code looks in the wrong place in the registry and hence don't get the correct data.
I cannot reproduce it anymore on Windows... The original user had issue on Linux and I commented the problematic call in unix.py as a temporary solution(https://github.com/morpheus65535/bazarr/commit/f0fd8877ae6551a870cdba7d84236a5462aa4c83).
I suppose we can close this one and I'll reopen it if I have issue with it again.
I started having this problem. I don't know when it started, because I have not run this code on my Windows 10 machine for a while, but now ...:
# python -i
Python 2.7.16 (v2.7.16:413a49145e, Mar 4 2019, 01:37:19) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import tzlocal
>>> tz = tzlocal.get_localzone()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Users\livily3\.virtualenvs\test\lib\site-packages\tzlocal\win32.py", line 95, in get_localzone
utils.assert_tz_offset(_cache_tz)
File "C:\Users\livily3\.virtualenvs\test\lib\site-packages\tzlocal\utils.py", line 38, in assert_tz_offset
raise ValueError(msg)
ValueError: Timezone offset does not match system offset: -25200 != 3600. Please, check your config files.
>>>
#
This is Windows 10 version 1709 build 16299.1268, and Python 2.7.16 in a virtualenv. This is my work machine and there are setting I cannot change. The time zone is (UTC-08:00) Pacific Time (US & Canada). When I look at the Date and Time Settings, the "Adjust for daylight saving time automatically" button is on, which is also one of the options that I can't change. Is it possible that Windows sets the wrong time zone while trying to be helpful with DST?
# tzutil /g
Pacific Standard Time
# pip list | grep tz
pytz 2019.1
tzlocal 2.0.0
After some more poking around, this appears to be an interaction between Cygwin and tzlocal. The same problem does not occur in a cmd window.
It's not DST, the offsets are wildly different. In fact, the error says that the offset tzlocal expects is -25200 minutes, but the offset reported by the system via the time library is 3600.
Pacific Standard Time should give you -25200, so it seems the time library does something different there.
One question I have is if you have a TZ environment variable set? The other is that your prompt is a has tag, that's not a common Windows prompt. Are you running some sort of unixy shell? Could that have it's own timezone config?
I am running a Cygwin shell, which is indeed a unixy shell. If you are not familiar with it and I am not mistaken, Cygwin mimics a Linux system by compiling the sources with a DLL built to translate the Linux system calls to Windows. It does have the TZ environment variable set:
# echo $TZ
America/Los_Angeles
It could be some interaction between Cygwin and Windows, absolutely. I had recently updated Cygwin as well, so this probably started when I did that. I may be able to figure out what was updated; I'm not sure since I'm not that familiar with Cygwin's update mechanism. I also don't know what I'm looking for, so that does make it more difficult.
I did a tiny bit of poking around and I don't see that there are any bugs about Cygwin and timezones after 2016, and nothing that resembles the problem I'm having. Like I said, it does not occur in a Windows cmd window, so I do have a fallback to keep working on my problem...
Huh, that TZ should be the same as the Pacific Zone you have in Windows, so that's strange. I guess I have to install cygwin and see if I can replicate it.
In fact, it is the same, which is another thing that I don't understand... I don't know if this is a Cygwin bug or a tzlocal bug or a Windows bug or a ... ???, none of which I am particularly familiar with.
If there's something I can run on my systems here to help, just let me know. Thanks very much for your assistance.
We have the same issue when using tzlocal
inside a Windows Container. It seems that inside the container, the registry key you are reading does not correspond to the actually active timezone:
PS C:\> tzutil /g
W. Europe Standard Time
PS C:\> Get-TimeZone
Id : W. Europe Standard Time
DisplayName : (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna
StandardName : W. Europe Standard Time
DaylightName : W. Europe Daylight Time
BaseUtcOffset : 01:00:00
SupportsDaylightSavingTime : True
PS C:\> REG QUERY HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
Bias REG_DWORD 0x1e0
DaylightBias REG_DWORD 0xffffffc4
DaylightName REG_SZ @tzres.dll,-211
DaylightStart REG_BINARY 00000300020002000000000000000000
StandardBias REG_DWORD 0x0
StandardName REG_SZ @tzres.dll,-212
StandardStart REG_BINARY 00000B00010002000000000000000000
TimeZoneKeyName REG_SZ Pacific Standard Time
DynamicDaylightTimeDisabled REG_DWORD 0x0
ActiveTimeBias REG_DWORD 0x1a4
PS C:\> python -c "import tzlocal; print(tzlocal.get_localzone())"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "C:\venv\lib\site-packages\tzlocal\win32.py", line 95, in get_localzone
utils.assert_tz_offset(_cache_tz)
File "C:\venv\lib\site-packages\tzlocal\utils.py", line 38, in assert_tz_offset
raise ValueError(msg)
ValueError: Timezone offset does not match system offset: -25200 != 7200. Please, check your config files.
We are also getting the same problem on Cygwin on Windows after upgrading to tzlocal v2.0.0.
~ python -c "import tzlocal; print(tzlocal.get_localzone())"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "C:\Cygwin\home\Administrator\python\lib\site-packages\tzlocal-2.0.0-py2.7.egg\tzlocal\win32.py", line 95, in get_localzone
utils.assert_tz_offset(_cache_tz)
File "C:\Cygwin\home\Administrator\python\lib\site-packages\tzlocal-2.0.0-py2.7.egg\tzlocal\utils.py", line 38, in assert_tz_offset
raise ValueError(msg)
ValueError: Timezone offset does not match system offset: 10800 != 3600. Please, check your config files.
I found that time.altzone
in this environment shows "-3600" (one hour) even though I am in UTC+3 (should be -10800).
I found that unsetting the TZ
environment variable fixes this problem (this variable holds the correct value, Asia/Jerusalem
- so maybe it's a bug in Python's time
module?)
In my case, it seems to be a Cygwin bug. I did notice that there were new Cygwin tz files available a few days ago, and now I no longer see the problem. So perhaps the same solution would help @wiggin15. Thanks for taking a look @regebro.
Thanks for your suggestion @lyssalivingston . Unfortunately, upgrading Cygwin and its packages did not help.
# cygcheck -c | egrep "(cygwin|tz)" 19-09-11 10:35
base-cygwin 3.8-1 OK
cygwin 3.0.7-1 OK
cygwin-devel 3.0.7-1 OK
tzcode 2019b-1 OK
tzdata 2019b-1 OK
# python -c "import tzlocal; print(tzlocal.get_localzone())" 19-09-11 10:35
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "C:\Cygwin\home\Administrator\python\lib\site-packages\tzlocal-2.0.0-py2.7.egg\tzlocal\win32.py", line 95, in get_localzone
utils.assert_tz_offset(_cache_tz)
File "C:\Cygwin\home\Administrator\python\lib\site-packages\tzlocal-2.0.0-py2.7.egg\tzlocal\utils.py", line 38, in assert_tz_offset
raise ValueError(msg)
ValueError: Timezone offset does not match system offset: 10800 != 3600. Please, check your config files.
I apologize @wiggin15. I was completely wrong. I had been running in a Windows cmd shell and mistakenly thought it was my Cygwin shell. When I ran the code again in the Cygwin shell, I still had the problem. Maybe I should change background colors...
I got this issue when using America/Santiago on Windows 10 with Python 2.7.15.