Checked for patches today, applied glibc-zoneinfo-2020b-noarch-1_slack14.0 and time is in a bad state. No tz indicated in time, system jumped to display UTC (0 offest) instead of CDT.

All attempts to set timezone seem to succeed - yet no change.

Copied older /etc/localtime file from another system and immediately everything went back to normal.

Confirmed. Something is off with the 2020b update. Same result as you: No timezone after upgradepkg. Different zone than you so it isn't just yours.

To fix, I reverted to the previous version: upgradepkg glibc-zoneinfo-2020a-noarch-1_slack14.2.txz

All I checked so far is that the update did properly copy the file referenced in /etc/localtime-copied-from into /etc/localtime. So the problem seems to be with the actual zoneinfo files.

Thanks for the heads-up. I have 14.2 but I haven't done my monthly update yet. My /etc/localtime is a link to /usr/share/zoneinfo/Europe/London, so I've copied that file over as /etc/localtime.backup just in case I run into problems.

[Edit: removed Emojis, the forum software doesn't seem to like them]

Same here. Posted a lengthy bug report here yesterday, but as it seems it hasn't quite made it through moderation yet.

Fix: get the upstream sources from IANA (URL is in the slack-desc, you'll need the tzcode2020a.tar.gz and tzdata2020a.tar.gz packages - there's no direkt link to older versions anymore, but you can simply replace the "b" from the current version with an "a"), run them through the original glibc-zoneinfo.SlackBuild script, and upgradepkg the resulting package.

Easy fix: just reinstall the old glibc-zoneinfo-2020a-noarch-1_slack14.2.txz that you kept around, unlike me, just in case.

Not sure yet if this is an upstream problem, a Slackware problem or a Slackware 32bit problem. I briefly checked the IANA tz mailing list archive for October, and there hasn't been a single message mentioning this or a similar problem as of today, let alone a huge "OMG, my system time is nailed to UTC, we're all gonna die!!!" outcry. Hmmm ...

At the moment, you can't get into IANA. You just get a screen saying "This website is currently undergoing maintenance. Thank you for your patience."

Maybe that means they're fixing the problem.

Just tried, getting the sources works fine, via both IPv4 and IPv6.

=> https://data.iana.org/time-zones/rel...de2020a.tar.gz
=> https://data.iana.org/time-zones/rel...ta2020a.tar.gz

They probably applied their own update, a few seconds passed, and then "Oh-oh, oops!". ;-)

OK, I've got them.

I also had same issue, didn't notice until this thread. a fixed it on my system.

Reinstall? You mean of the new 2020b package rather than the old 2020a one?

I just know that is what I ran to fix it. I did the update friday I think, ran the reinstall today.

Which suggests to me that Pat's already fixed the problem.

Just tried the reinstall from kernel.org mirror and got the older, broken file. 85435a33486747b319872947c68317f3 localtime was put back on my system - 1754 bytes.

that is weird, http://mirrors.us.kernel.org/slackwa...are64-current/ is what my mirror is set to and it is 2020b is installed.

see below

working version of the data file:
/usr/share/zoneinfo/US/Central: timezone data, version 2, 7 gmt time flags, 7 std time flags, no leap seconds, 236 transition times, 7 abbreviation chars

broken version of the data file:
/usr/share/zoneinfo/US/Central: timezone data, version 2, no gmt time flags, no std time flags, no leap seconds, no transition times, 1 abbreviation char