Consider checking which timezone path the system uses

I use Arch, which sets the timezone via the /etc/localtime symbolic link.

Recently I had a calendar program which was displaying events in the wrong timezone, despite things like date and timedatectl showing the correct timezone. I couldn’t figure out where it was getting the incorrect configuration from.

As it turns out, I had run tzupdate when I was in a different timezone, which both set the /etc/localtime link and wrote the timezone to /etc/timezone. Later, when I returned to my home timezone, I changed the timezone back using a different method, such that /etc/localtime was correct but the /etc/timezone file that tzupdate created still showed the wrong timezone. This was where the calendar program was getting the incorrect date from.

It would be nice if tzupdate only modified the file used by the system. The easiest solution would be to not touch either file unless they already exist, but I see in #11 that tzupdate intentionally accounts for the odd case of a system which has no timezone configured yet.

Instead, maybe the best option is to check /etc/issue, if the contents look Debian-ish set /etc/timezone, otherwise set /etc/localtime.

[pigmonkey]

Yeah, I poked around on an Ubuntu box I have and it looks like it does need both, so I think always setting /etc/localtime and saving the conditional just for /etc/timezone makes sense.

[cdown]

Thanks for taking a look.

06646ee094536a984645626274607334db4043a6 should implement this for future cases, although for boxes with /etc/timezone already on, it will need to be manually removed.

Thanks for the report!