Multiple conflicting time zone configurations

[neomis]

Running on Ubuntu 16.04 I'm getting this error with tzlocal >= 4.0.1

Python 3.8.3 (default, Sep  2 2020, 09:15:06) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from tzlocal import get_localzone
>>> get_localzone()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/dispo/test_pytz/lib/python3.8/site-packages/tzlocal/unix.py", line 205, in get_localzone
    _cache_tz = _get_localzone()
  File "/home/dispo/test_pytz/lib/python3.8/site-packages/tzlocal/unix.py", line 167, in _get_localzone
    tzname = _get_localzone_name(_root)
  File "/home/dispo/test_pytz/lib/python3.8/site-packages/tzlocal/unix.py", line 146, in _get_localzone_name
    raise utils.ZoneInfoNotFoundError(message)
tzlocal.utils.ZoneInfoNotFoundError: 'Multiple conflicting time zone configurations found:\n/etc/timezone: America/Denver\n/etc/sysconfig/clock: America/Denver\n/usr/share/zoneinfo/Navajo: Navajo\nFix the configuration, or set the time zone in a TZ environment variable.\n'```

cat /etc/timezone
America/Denver

cat /etc/sysconfig/clock
ZONE="America/Denver"
UTC=false
ARC=false

I don't know why it's checking /usr/share/zoneinfo/Navajo?

[regebro]

Your /etc/localzone is a symlink to /usr/share/zoneinfo/Navajo.

I should make that information clearer...

[regebro]

Done. 4.0.2 released with a clearer error message in this case.

[neomis]

This was an odd one. /etc/localtime was symlinked to /usr/share/zoneinfo/America/Denver. /usr/share/zoneinfo/America/Denver was symlinked to /usr/share/zoneinfo/Navajo. I don't know how that happened. I appear to be running the latest tzdata package in Ubuntu 16.04. I grabbed the correct timezone file off a newer system and everything works now.

Thanks for the quick response and the better error message.

[regebro]

Huh, yeah, that's odd, looking it up I see that Navajo should link to America/Denver, not the other way around.

[regebro]

I'll pin this issue, and if there are more systems with these links backwards, I might have to look each config up. In this case, if I had checked if America/Denver was a symlink, you would have not gotten an error. On the other hand, tzlocal might then have returned "Navajo", which I guess also would be surprising. :-)

[davejennings]

Another one I think. :)

Ubuntu 18.04
tzlocal 4.0.2

$ ls -l /etc/localtime 
lrwxrwxrwx 1 root root 33 Oct 28 05:53 /etc/localtime -> /usr/share/zoneinfo/Europe/London
$ ls -l /usr/share/zoneinfo/Europe/London
lrwxrwxrwx 1 root root 5 Sep 29 20:14 /usr/share/zoneinfo/Europe/London -> ../GB

Python 3.6.9 (default, Jan 26 2021, 15:33:00) 
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from tzlocal import get_localzone
>>> get_localzone()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.6/dist-packages/tzlocal/unix.py", line 206, in get_localzone
    _cache_tz = _get_localzone()
  File "/usr/local/lib/python3.6/dist-packages/tzlocal/unix.py", line 168, in _get_localzone
    tzname = _get_localzone_name(_root)
  File "/usr/local/lib/python3.6/dist-packages/tzlocal/unix.py", line 147, in _get_localzone_name
    raise utils.ZoneInfoNotFoundError(message)
tzlocal.utils.ZoneInfoNotFoundError: 'Multiple conflicting time zone configurations found:\n/etc/timezone: Europe/London\n/etc/localtime is a symlink to: GB\nFix the configuration, or set the time zone in a TZ environment variable.\n'

[regebro]

Yeah, looks like it.

Why did they add those annoying links, like GB? :angry old man yells at cloud.gif:

[brianmaissy]

another:

$ ll /etc/localtime
lrwxrwxrwx 1 root root 34 Oct 10 12:17 /etc/localtime -> /usr/share/zoneinfo/Asia/Jerusalem
$ ll /usr/share/zoneinfo/Asia/Jerusalem
lrwxrwxrwx 1 root root 9 Sep 29 22:14 /usr/share/zoneinfo/Asia/Jerusalem -> ../Israel

also Ubuntu 18.04

This is a strange suggestion, but if /etc/timezone matches the name of the first-level symlink of /etc/localtime, maybe it would be the "correct" answer to return that, rather than following the second link?

But yeah, it does seem like the links are backwards. Navajo, GB, and Israel, for example, appear in the https://data.iana.org/time-zones/code/backward file. Could it be that somehow the links were reversed? I think I'm out of my depth here; I got lost in the Makefile

[regebro]

os.path.realpath() just returns the real path, any middle symlinks are hidden, so doing it that way will be tricky. But I think what I have is a good solution.

I have released 4.1b1, please test it.

[brianmaissy]

looks good; works for me 👍 thanks!

[davejennings]

Cheers @regebro, also working for me though I now get this output:

2021-10-28 13:55:37,133: /usr/local/lib/python3.6/dist-packages/apscheduler/util.py:95: PytzUsageWarning: The zone attribute is specific to pytz's interface; please migrate to a new time zone provider. For more details on how to do so, see https://pytz-deprecation-shim.readthedocs.io/en/latest/migration.html
  if obj.zone == 'local':
/usr/local/lib/python3.6/dist-packages/apscheduler/util.py:166: PytzUsageWarning: The localize method is no longer necessary, as this time zone supports the fold attribute (PEP 495). For more details on migrating to a PEP 495-compliant implementation, see https://pytz-deprecation-shim.readthedocs.io/en/latest/migration.html
  return tz.localize(datetime_, is_dst=None)
INFO:elastalert:Starting up
2021-10-28 13:55:37,134: /usr/local/lib/python3.6/dist-packages/apscheduler/triggers/interval.py:66: PytzUsageWarning: The normalize method is no longer necessary, as this time zone supports the fold attribute (PEP 495). For more details on migrating to a PEP 495-compliant implementation, see https://pytz-deprecation-shim.readthedocs.io/en/latest/migration.html
  return self.timezone.normalize(next_fire_time)

[davejennings]

Hah although I didn't clock that wasn't referring to your tzlocal package, my bad. Assume it's all fine. 👍

[regebro]

@davejennings That great! The warnings are expected. Are you explicitly using pytz? If not you may want to modify your code to use the standard datetime way of dealing with timezones instead. It's been updated to handle the cases that it could not handle earlier, so the pytz API isn't needed any more.

IIRC (it's a year since I did this, I may misremember) instead of localize() you use the replace() function on the datetime to make a naive datetime into a timezone aware one, and you no longer need to call normalize() after converting to another timezone.

https://pytz-deprecation-shim.readthedocs.io/en/latest/migration.html has more information on the differences.
But there is no panic in doing this, I won't drop the pytz shim for at least a year, probably longer since I'm lazy.

[dakide]

There's another one:

ls -l /etc/localtime 
/etc/localtime -> /usr/share/zoneinfo/America/Toronto

ls -l /usr/share/zoneinfo/America/Toronto
/usr/share/zoneinfo/America/Toronto -> Montreal

[regebro]

@dakide Can you see if tzlocal==4.1b1 works for you?

[dakide]

@regebro yes it does, thank you!

[regebro]

OK, no new issues for a few days, I released this as 4.1.

[D3vil0p3r]

Solved by having /etc/localtime pointing to a timezone that is the same in /etc/timezone file.