I am running debian. Sometime in the past month, when I received a kernel upgrade and also a tzdata upgrade, I noticed that the time was wrong on my system.

Today, I saw (apt list --upgradable) that another tzdata update was coming. Before I ran apt upgrade, I checked the following:

/etc/localtime -> pointed as shortcut to correct timezone
/etc/timezone -> contained the correct timezone

I watched the apt upgrade run. When it came time for tzdata to reconfigure, it said:

Current default time zone: 'America/Indiana/Indianapolis'

Which is wrong.

/etc/localtime and /etc/timezone were both now pointed to Indianapolis, which is wrong and not what they said right before the upgrade.

So I ran dpkg-reconfigure and got it fixed again.

Out of curiousity, I also ran dkpg-reconfigure and then selected "cancel" without making any choices. Guess what? tzdata set me back to "Indianapolis"!

This is happening on every debian/devuan/raspbian system that I have, and it started happening sometime during the past month or six weeks after I received a kernel/tzdata update.

I thought the time zone was saved in the two above places in /etc. Is there some other place that tzdata is reading from that I need to look at so that, in future, whenever tzdata gets updated I don't have to remember to go back and manually fix the time zone each time?

Thanks!
---
� Synchronet � CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP

Hey Dumas!

On Tue, 01 Apr 2025 14:37:40 -0500, you wrote:

I am running debian. Sometime in the past month, when I received a
kernel upgrade and also a tzdata upgrade, I noticed that the time was wrong on my system.

/etc/localtime -> pointed as shortcut to correct timezone
/etc/timezone -> contained the correct timezone

This might depend on if you're using systemd or not. In my case (Archlinux), I have '/etc/localtime' which is symlinked to the correct timezone in '/usr/share/zoneinfo'. I don't have '/etc/timezone', and I use ntpd to keep my time synced.

I disabled systemd-timesyncd awhile back, due to my clock being off at some point, but I don't remember exactly when. It was definitely much longer ago (months/years probably) than what you're encountering recently.

Seeing as how you're using Debian and Devuan (one can only assume here that one has systemd and the other does not, since you didn't specify), you may want to check to see if 'ntpd' is installed and running properly:

systemd command:

$ sudo systemctl status ntpd.service
� ntpd.service - Network Time Service
Loaded: loaded (/usr/lib/systemd/system/ntpd.service; enabled; preset: disabled)
Active: active (running) since Mon 2025-03-31 17:58:44 CDT; 24h ago

journalctl (logs):

Mar 31 17:58:53 reaper ntpd[422]: new interface(s) found: waking up resolver

On non-systemd you probably have to do something like: 'sudo service ntpd status' or some such. It's been awhile since I've used sysvinit.

This is happening on every debian/devuan/raspbian system that I have,
and it started happening sometime during the past month or six weeks
after I received a kernel/tzdata update.

Does tzdata actually do anything, though? Pretty sure it simply just provides the time zone information needed for all other applications or runtimes in the operating system to print local time correctly. I can't imagine tzdata is to blame, here.. unless the Debian maintainers completely jacked that package up, and for Debian variants only.

When you type 'sudo hwclock' what do you see? Is it displaying the correct timezone offset? And does it match your results for the 'date' command?

Here (and yes I did them a couple minutes apart ;)):
$ sudo hwclock
2025-04-01 19:37:40.996551-05:00

$ date
Tue Apr 1 07:39:28 PM CDT 2025

I thought the time zone was saved in the two above places in /etc. Is there some other place that tzdata is reading from that I need to look
at so that, in future, whenever tzdata gets updated I don't have to remember to go back and manually fix the time zone each time?

Those are probably the two most common places, but might vary slightly between distros. I think tzdata is what is read (by other applications), and doesn't do any reading of anything on it's own (but I could be wrong). I can't imagine this is tzdata's fault, though, or it would be all over the Linux interwebz since it's a pretty important package, and not just specific to you.

If you don't have some kind of application or service setup to sync and retain your time and timezone information, I recommend using one.

Regards,
Nick

... Sarcasm: because beating people up is illegal.
--- GoldED+/LNX 1.1.5-b20240604
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (723:1/1)
� Synchronet � _thePharcyde telnet://bbs.pharcyde.org (Wisconsin)

/etc/localtime -> pointed as shortcut to correct timezone
/etc/timezone -> contained the correct timezone

This might depend on if you're using systemd or not. In my case (Archlinux), I
have '/etc/localtime' which is symlinked to the correct timezone in '/usr/share/zoneinfo'. I don't have '/etc/timezone', and I use ntpd to keep my
time synced.

/etc/localtime is symlinked to the correct timezone until a tzdata update
is received, then it resets it to "Indianapolis."

Seeing as how you're using Debian and Devuan (one can only assume here that on
has systemd and the other does not, since you didn't specify), you may want to
check to see if 'ntpd' is installed and running properly:

Correct re: systemd and not. ;)

This is happening on every debian/devuan/raspbian system that I have, and it started happening sometime during the past month or six weeks after I received a kernel/tzdata update.

Does tzdata actually do anything, though? Pretty sure it simply just provides the time zone information needed for all other applications or runtimes in the
operating system to print local time correctly. I can't imagine tzdata is to blame, here.. unless the Debian maintainers completely jacked that package up,
and for Debian variants only.

At the very least, tzdata resets /etc/localtime and /etc/timezone, which the system and other applications use to determine the local timezone and
therefore correct time vs. GMT. So it does do "something." ;)

When you type 'sudo hwclock' what do you see? Is it displaying the correct timezone offset? And does it match your results for the 'date' command?

Yes, it is correct right now. Not sure if it would be if I were to let
tzdata run again.

I thought the time zone was saved in the two above places in /etc. Is there some other place that tzdata is reading from that I need to look at so that, in future, whenever tzdata gets updated I don't have to remember to go back and manually fix the time zone each time?

Those are probably the two most common places, but might vary slightly between
distros. I think tzdata is what is read (by other applications), and doesn't d
any reading of anything on it's own (but I could be wrong). I can't imagine this is tzdata's fault, though, or it would be all over the Linux interwebz since it's a pretty important package, and not just specific to you.

I don't think it is "tzdata's fault," per se, but it very obviously on my systems has "Indianapolis" saved *somewhere* other than the two places I
would know to look.... /etc/timezone and /etc/localtime... and I need to
find it and quash it. ;)

I have checked in /etc, /var, and a couple of other places for a config
file but don't see one. Someone else suggested running grep on the
contents of /etc and looking for "Indianapolis." I will try that if I can figure out how to get grep to run on a whole directory?

If you don't have some kind of application or service setup to sync and retain
your time and timezone information, I recommend using one.

Will ntpd use the hwclock time to determine this, or does it rely on /etc/localtime? If it uses the latter, I suspect it will be wrong, too. ;)


* SLMR 2.1a * Overhead the albatross hangs motionless upon the air...
---
� Synchronet � CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP

Hey Dumas!

On Wed, 02 Apr 2025 09:19:00 -0500, you wrote:

/etc/localtime is symlinked to the correct timezone until a tzdata
update is received, then it resets it to "Indianapolis."

What is it supposed to be all of the time? I don't think you ever mentioned that.

Yes, it is correct right now. Not sure if it would be if I were to let tzdata run again.

You may have to in order to get to the bottom of this.

While using or not using systemd may need different routes, this link seems pretty solid for Debian:

https://linuxcapable.com/how-to-set-timezone-on-debian-linux/

If your timezone information is currently correct, you could try to save your current configuration to hardware with:

$ sudo hwclock --systohc

Otherwise, take a look at:

https://wiki.debian.org/TimeZoneChanges
https://wiki.debian.org/DateTime

In the second link, it does mention setting automatically with ntp/ntpd.

As for non-systemd specific stuff, the two wiki links above seem to do things without the use of systemd or sysvinit related stuff.. so maybe that's a better route to get them all sync'd via the same method.

I don't think it is "tzdata's fault," per se, but it very obviously on
my systems has "Indianapolis" saved *somewhere* other than the two
places I would know to look.... /etc/timezone and /etc/localtime... and
I need to find it and quash it. ;)

$ sudo grep -Ril "Indianapolis" /etc

Should find it if it exists.

I have checked in /etc, /var, and a couple of other places for a config file but don't see one. Someone else suggested running grep on the contents of /etc and looking for "Indianapolis." I will try that if I
can figure out how to get grep to run on a whole directory?

There's not too many places this could be set that would affect anything. And since it seems the exact same thing is happening on 3 systems, some using systemd and some not, makes it much more vague, but if you're not running some kind of time synchronization, and none of the above suggestions work, that would probably be your answer (ntp/ntpd).

Will ntpd use the hwclock time to determine this, or does it rely on /etc/localtime? If it uses the latter, I suspect it will be wrong, too. ;)

Take a look and see, but I believe it sets /etc/timezone, /etc/localtime, and your hardware clock after synchronization, https://wiki.debian.org/NTP

Less distro specific, but more explanation at https://www.ntp.org.

I'd bet Devuan and the Raspi wikis probably have something very similar.

NTP is probably one of, if not the most used time synchronization daemon/clients around.

I hope any of that long winded response helps. :)

Regards,
Nick

... Sarcasm: because beating people up is illegal.
--- GoldED+/LNX 1.1.5-b20250401
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (723:1/1)
� Synchronet � _thePharcyde telnet://bbs.pharcyde.org (Wisconsin)