ValueError: Timezone offset does not match system offset: 7200 != 3600. Please, check your config files.
mowgli opened this issue · comments
With commit 1d9774a the library got a check if the local timezone differ from the system one.
On a proper unix system that is very common. For example having the system time set to UTC but the user TZ variable set to the local time zone. Or in my case the system time set to CEST but my user TZ environment TO CET.
That change breaks several third party tools as, for example, tasklib. It prevents them from running at all.
Please revert that commit. There is nothing that can be checked if the local TZ differs from something else. In a proper unix/linux system with multiple users you will always see differences here. That is no error.
I see that this bug is the same than #73. Feel free to merge.
Right, that check should at least not be done if you have TZ set, that's true. Looking into this.
@regebro Any news about this bug? Thanks!
Please reopen that bug, I still get the error.
Fehler beim Ausführen von "/home/klaus/.vim/pack/task/start/taskwiki/ftplugin/vimwiki/taskwiki.vim":
Zeile 33:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/home/klaus/.vim/pack/task/start/taskwiki/taskwiki/main.py", line 15, in <module>
from taskwiki import cache as cache_module
File "/home/klaus/.vim/pack/task/start/taskwiki/taskwiki/cache.py", line 6, in <module>
from taskwiki import viewport
File "/home/klaus/.vim/pack/task/start/taskwiki/taskwiki/viewport.py", line 6, in <module>
from taskwiki import vwtask
File "/home/klaus/.vim/pack/task/start/taskwiki/taskwiki/vwtask.py", line 7, in <module>
from tasklib import Task
File "/usr/lib/python3.7/site-packages/tasklib/__init__.py", line 1, in <module>
from .backends import TaskWarrior
File "/usr/lib/python3.7/site-packages/tasklib/backends.py", line 12, in <module>
from .task import Task, TaskQuerySet, ReadOnlyDictView
File "/usr/lib/python3.7/site-packages/tasklib/task.py", line 10, in <module>
from .serializing import SerializingObject
File "/usr/lib/python3.7/site-packages/tasklib/serializing.py", line 12, in <module>
local_zone = tzlocal.get_localzone()
File "/usr/lib/python3.7/site-packages/tzlocal/unix.py", line 165, in get_localzone
_cache_tz = _get_localzone()
File "/usr/lib/python3.7/site-packages/tzlocal/unix.py", line 90, in _get_localzone
utils.assert_tz_offset(tz)
File "/usr/lib/python3.7/site-packages/tzlocal/utils.py", line 38, in assert_tz_offset
raise ValueError(msg)
ValueError: Timezone offset does not match system offset: 7200 != 3600. Please, check your config files.
My timezone (TZ) is still set to CET-1 while the system one is set to CEST currently (That changes in wintertime when the timezones matches.)
Let me ask, what sense should it make to check the match of that two timezones at all? There is nothing in the unix world that makes less sense.
The system time zone is only relevant for the system admin (to be able to match logfiles or such stuff) It is absolutly irrelevant for users when they set their TZ environment.
@mowgli I solved this by making sure my /etc/localtime was correct. On most Linux distributions, you have to install the package tzdata and then copy or symlink the correct timezone data file to /etc/localtime. For example:
cp /usr/share/zoneinfo/Europe/Brussels /etc/localtime
Btw, the change to only test the offset if you are using the system config was changed in 2019, so maybe mowgli was using an old version.
This is currently only an issue if you are using Unix environments on Windows where your Unix environment is configured to another timezone than the Windows environment, which is a misconfiguration. I think that's an OK check to have, but I'm not religious about it.
@iFreilicht: Well, the /etc/localtime is only correct in system context, seldom in user context. The user context zone is defined with TZ environment variable. Unix systems (which includes linux systems) often have many users on it that comes from different time locations. The /etc/localtime setting is completely meaningless.
@regebro: My issue is explicitly on linux. I never had any windows environment. This issue exists due to the misconception of taking /etc/localtime into consideration. As stated above, usually only the TZ environment is the relevant one with /etc/localtime only as fallback.
If you set TZ, it doesn't do this check, so you shouldn't be able to get the error.