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?
On Ubuntu I've only once set /etc/localtime to symlink to /usr/share/zoneinfo/Europe/Amsterdam (in my case). As described in 'man 5 localtime'. I've never touched or editted /etc/timezone. That might be set automatically (on boot, but I don't really know), from where /etc/localtime links to...
This is on multiple servers, that have been running for years, and are kept to date regularly.
On Ubuntu I've only once set /etc/localtime to symlink to
/usr/share/zoneinfo/Europe/Amsterdam (in my case). As described in 'man
5 localtime'. I've never touched or editted /etc/timezone. That might
be set automatically (on boot, but I don't really know), from where
/etc/localtime links to... This is on multiple servers, that have been
running for years, and are kept to date regularly.
Yes, I also did that and it was also working until the recent update I mentioned. Now, I can symlink /etc/localtime to the correct timezone and it
will only stay set until the next time tzdata is updated. tzdata ignores what
is in the /etc/localtime symlink and resets it to point to "America/Indiana/Indianapolis."
So it is reading that information ("America/Indiana/Indianapolis") from somewhere that is not /etc/localtime and is also not /etc/timezone. I would
like to figure out where from so I can squash it.
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.
Re: Re: tzdata question
By: Wilfred van Velzen to Mike Powell on Tue Apr 01 2025 21:54:17
On Ubuntu I've only once set /etc/localtime to symlink to /usr/share/zoneinfo/Europe/Amsterdam (in my case). As described in
'man 5 localtime'. I've never touched or editted /etc/timezone.
That might be set automatically (on boot, but I don't really
know), from where /etc/localtime links to...
This is on multiple servers, that have been running for years, and
are kept to date regularly.
Yes, I also did that and it was also working until the recent update I mentioned. Now, I can symlink /etc/localtime to the correct timezone
and it will only stay set until the next time tzdata is updated.
tzdata ignores what is in the /etc/localtime symlink and resets it to
point to "America/Indiana/Indianapolis."
So it is reading that information ("America/Indiana/Indianapolis")
from somewhere that is not /etc/localtime and is also not
/etc/timezone. I would like to figure out where from so I can squash
it. --- SBBSecho 3.20-Linux
* Origin: capitolcityonline.net * Telnet/SSH:2022/HTTP (1:2320/105)
So it is reading that information ("America/Indiana/Indianapolis")
from somewhere that is not /etc/localtime and is also not
/etc/timezone. I would like to figure out where from so I can squash
it. --- SBBSecho 3.20-Linux
Did you try running grep in /etc and looking for Indiana?
I use neither of the methods either of you mentioned for setting the timezone. I use datetimectl for that, which just updates /etc/localtime anyway, I guess.
So it is reading that information ("America/Indiana/Indianapolis")
from somewhere that is not /etc/localtime and is also not
/etc/timezone. I would like to figure out where from so I can
squash it. --- SBBSecho 3.20-Linux
Did you try running grep in /etc and looking for Indiana?
I use neither of the methods either of you mentioned for setting the timezone. I use datetimectl for that, which just updates
/etc/localtime anyway, I guess.
I only use tzdata because it installed by default and I presumed that
other packages depend on it. Does datetimectl do the same thing?
Mike
* SLMR 2.1a * I had another drink...Drink-a-drink-a-drink-a-drink...
--- SBBSecho 3.20-Linux
* Origin: capitolcityonline.net * Telnet/SSH:2022/HTTP (1:2320/105)
I only use tzdata because it installed by default and I presumed that other packages depend on it.
Does datetimectl do the same thing?
On Ubuntu I've only once set /etc/localtime to symlink to /usr/share/zoneinfo/Europe/Amsterdam (in my case). As described in
'man 5 localtime'. I've never touched or editted /etc/timezone. That might be set automatically (on boot, but I don't really know), from
where /etc/localtime links to...
This is on multiple servers, that have been running for years, and are kept up
to date regularly.
Current default time zone: 'Europe/Amsterdam'
Local time is now: Thu Apr 3 10:29:57 CEST 2025.
Universal Time is now: Thu Apr 3 08:29:57 UTC 2025.
Run 'dpkg-reconfigure tzdata' if you wish to change it.
All went smoothly.
/etc/localtime and /etc/timezone have a new timestamp (set to the date/time of
the update). And are still correct...
Current default time zone: 'Europe/Amsterdam'
Current default time zone: 'Europe/Amsterdam'
Local time is now: Thu Apr 3 10:29:57 CEST 2025.
Universal Time is now: Thu Apr 3 08:29:57 UTC 2025.
Run 'dpkg-reconfigure tzdata' if you wish to change it.
All went smoothly.
/etc/localtime and /etc/timezone have a new timestamp (set to the date/time
of the update). And are still correct...
The new timestamps show that tzdata updated the both of them.
Where is it getting this info from to update those two datasets?
Sysop: | Angel Ripoll |
---|---|
Location: | Madrid, Spain |
Users: | 14 |
Nodes: | 8 (0 / 8) |
Uptime: | 119:00:16 |
Calls: | 817 |
Files: | 14,866 |
Messages: | 70,708 |