Latest zoneinfo breaks clock in 32-bit Slackware machine
by KISSAndStable from LinuxQuestions.org on (#59104)
REPORTING.
glibc-zoneinfo-2020b breaks the clock in a 32-bit Slackware machine. After this update, nothing but the current UTC would display. Even using 'date -set', and whatever time you choose to type in, the result displayed is always the current UTC. 'timeconfig' does not reset to localtime. Etc. The time is always current UTC. It's all broken.
Maybe the timezone files are now compiled for 64-bit, and thus cannot be correctly interpreted by a 32-bit environment? 'file' was not very revelatory. But here's a hint that this is so:
glibc-zoneinfo-2020b (the new version that doesn't work in 32-bit), 'ls -l' gives the 'USPacific' filelength as
1294
glibc-zoneinfo-2020a (the just-previous version that DOES work in 32-bit) 'ls -l' gives the 'USPacific' filelength as
2836
VERY different filelengths.
glibc-zoneinfo-2020b breaks the clock in a 32-bit Slackware machine. After this update, nothing but the current UTC would display. Even using 'date -set', and whatever time you choose to type in, the result displayed is always the current UTC. 'timeconfig' does not reset to localtime. Etc. The time is always current UTC. It's all broken.
Maybe the timezone files are now compiled for 64-bit, and thus cannot be correctly interpreted by a 32-bit environment? 'file' was not very revelatory. But here's a hint that this is so:
glibc-zoneinfo-2020b (the new version that doesn't work in 32-bit), 'ls -l' gives the 'USPacific' filelength as
1294
glibc-zoneinfo-2020a (the just-previous version that DOES work in 32-bit) 'ls -l' gives the 'USPacific' filelength as
2836
VERY different filelengths.