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!
--- SBBSecho 3.20-Linux
* Origin: capitolcityonline.net * Telnet/SSH:2022/HTTP (1:2320/105)

Hi Mike,

On 2025-04-01 14:36:39, you wrote to All:

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 up to date regularly.


Bye, Wilfred.

--- FMail-lnx64 2.3.2.4-B20240523
* Origin: FMail development HQ (2:280/464)

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)

Hi Mike,

On 2025-04-01 15:16:50, you wrote to me:

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.

Sorry, then I have no clue...


Bye, Wilfred.

--- FMail-lnx64 2.3.2.4-B20240523
* Origin: FMail development HQ (2:280/464)

Hello Mike!

01 Apr 25 14:36, you wrote to all:

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 did a deep dive search on three different search engines and I could not find anything for Debian but I did see talk in Ubuntu forms about a bug in tzdata.

I'd recommend going to a good Debian forum and seeing what kind of answer you get. I didn't see any in the Devuan forum about this. That is an odd problem though.

Wish I could offer more help.

-- Sean

... Time flies like an arrow but fruit flies like a banana.
--- GoldED+/LNX 1.1.5-b20240209
* Origin: Outpost BBS * Johnson City, TN (1:18/200)

On Tue, 1 Apr 2025 15:16:50 -0500
"Mike Powell" (1:2320/105) <Mike.Powell@f105.n2320.z1.fidonet> wrote:

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)

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.
--
End Of The Line BBS - Plano, TX
telnet endofthelinebbs.com 23
--- SBBSecho 3.24-Linux
* Origin: End Of The Line BBS - endofthelinebbs.com (1:124/5016)

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)

On Wed, 2 Apr 2025 08:50:00 -0500
"Mike Powell" (1:2320/105) <Mike.Powell@f105.n2320.z1.fidonet> wrote:

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)

Oh, it's just a program provided to give the user easy control over
date/time settings rather than dealing with symlinks and whatever.
--
End Of The Line BBS - Plano, TX
telnet endofthelinebbs.com 23
--- SBBSecho 3.24-Linux
* Origin: End Of The Line BBS - endofthelinebbs.com (1:124/5016)

I only use tzdata because it installed by default and I presumed that other packages depend on it.

They do, at least libc depends on it.

Does datetimectl do the same thing?

Timedatectl is used by systemd to set/change the timezone.

I wonder if rolling back to the previous tzdata package and holding it there wouold help, but I'm not sure.

If it does, that could indicate a packaging problem, not a tzdata problem.

I've had no problems here since the tzdata update. My systems are all SysV at the moment.

--- BBBS/Li6 v4.10 Toy-7
* Origin: The Rusty MailBox - Penticton, BC Canada (1:153/757)