Strange behaviour with recent glibc-zoneinfo-2020b-noarch-1 update

[Lew Pitcher]

I run 32bit Slackware 14.0 on one of my systems, and apply relevant
patches from Slackware when they become available. This afternoon, I
applied (using upgradepkg) the recent glibc-zoneinfo-2020b-
noarch-1_slack14.0 the over an existing (and working) glibc-
zoneinfo-2020a-noarch-1_slack14.0.

My motherboard RTC is set to UTC, as are the /etc/hardwareclock
parameters, and the /etc/localtime is copied from /usr/share/zoneinfo/
EST5EDT (and /etc/localtime-copied-from points to /usr/share/zoneinfo/
EST5EDT).

So, I was surprised at 8PM EDT tonight when a cron job scheduled for
midnight ran to completion. Once I gathered my whits, I checked the
system clock, which confirmed that as of 8PM wallclock time, the sytem
registered midnight. Both /etc/localtime and /etc/localtime-copied-from
were present, and /etc/localtime-copied-from pointed to the EST5EDT
zoneinfo file.

I immediately suspected the 2020b zoneinfo update, and reversed it out
(reapplying via upgradepkg the glibc-zoneinfo-2020a-noarch-1_slack14.0
patch.

With that done, the system correctly showed the wallclock time (now, just
past 8:30PM).

File tells me that the 2020b EST5EDT is:
timezone data, version 2, no gmt time flags, no std time flags,
no leap seconds, no transition times, 1 abbreviation char
and the 2020a EST5EDT is
timezone data, version 2, 5 gmt time flags, 5 std time flags,
no leap seconds, 149 transition times, 5 abbreviation chars

A properly updated 64bit 14.2 system, still showing the proper wallclock
time gives me, for the 2020b EST5EDT
timezone data, version 2, no gmt time flags, no std time flags,
no leap seconds, no transition times, 1 abbreviation char

So, a cautionary note: the glibc-zoneinfo-2020b-noarch-1_slack14.0
upgrade changed something radically. If you run 14.0, check that your
timezone data still applies properly after the upgrade.

[Lew Pitcher]

Post by Lew Pitcher
This afternoon, I
applied (using upgradepkg) the recent glibc-zoneinfo-2020b-
noarch-1_slack14.0 the over an existing (and working) glibc-
zoneinfo-2020a-noarch-1_slack14.0.

[snip]

Post by Lew Pitcher
So, I was surprised at 8PM EDT tonight when a cron job scheduled for
midnight ran to completion. Once I gathered my whits, I checked the
system clock, which confirmed that as of 8PM wallclock time, the sytem
registered midnight.

As a clarification: date(1) reported a wallclock time 4 hours forward of
actual wallclock time, as if my EST5EDT timezone was UTC+0 instead of
UTC-4 (for EDT).

Post by Lew Pitcher
Both /etc/localtime and /etc/localtime-copied-from
were present, and /etc/localtime-copied-from pointed to the EST5EDT
zoneinfo file.
I immediately suspected the 2020b zoneinfo update, and reversed it out
(reapplying via upgradepkg the glibc-zoneinfo-2020a-noarch-1_slack14.0
patch.
With that done, the system correctly showed the wallclock time (now,
just past 8:30PM).

Now, date(1) reported the same time as the wallclock (my cellphone,
actually).

[snip]

Post by Lew Pitcher
So, a cautionary note: the glibc-zoneinfo-2020b-noarch-1_slack14.0
upgrade changed something radically. If you run 14.0, check that your
timezone data still applies properly after the upgrade.

[Jimmy Johnson]

Post by Lew Pitcher
I run 32bit Slackware 14.0 on one of my systems, and apply relevant
patches from Slackware when they become available. This afternoon, I
applied (using upgradepkg) the recent glibc-zoneinfo-2020b-
noarch-1_slack14.0 the over an existing (and working) glibc-
zoneinfo-2020a-noarch-1_slack14.0.
My motherboard RTC is set to UTC, as are the /etc/hardwareclock
parameters, and the /etc/localtime is copied from /usr/share/zoneinfo/
EST5EDT (and /etc/localtime-copied-from points to /usr/share/zoneinfo/
EST5EDT).
So, I was surprised at 8PM EDT tonight when a cron job scheduled for
midnight ran to completion. Once I gathered my whits, I checked the
system clock, which confirmed that as of 8PM wallclock time, the sytem
registered midnight. Both /etc/localtime and /etc/localtime-copied-from
were present, and /etc/localtime-copied-from pointed to the EST5EDT
zoneinfo file.
I immediately suspected the 2020b zoneinfo update, and reversed it out
(reapplying via upgradepkg the glibc-zoneinfo-2020a-noarch-1_slack14.0
patch.
With that done, the system correctly showed the wallclock time (now, just
past 8:30PM).
timezone data, version 2, no gmt time flags, no std time flags,
no leap seconds, no transition times, 1 abbreviation char
and the 2020a EST5EDT is
timezone data, version 2, 5 gmt time flags, 5 std time flags,
no leap seconds, 149 transition times, 5 abbreviation chars
A properly updated 64bit 14.2 system, still showing the proper wallclock
time gives me, for the 2020b EST5EDT
timezone data, version 2, no gmt time flags, no std time flags,
no leap seconds, no transition times, 1 abbreviation char
So, a cautionary note: the glibc-zoneinfo-2020b-noarch-1_slack14.0
upgrade changed something radically. If you run 14.0, check that your
timezone data still applies properly after the upgrade.

The slackware system still works, but sometimes system installers get
things backwards and now you find a upgrade can screw things the wrong
way too. I multi-boot and just one system can screw them all. I set the
hardware clock, boot the system, set the local, set the time and run #
hwclock --systohc --localtime. Sorry I don't use utc, I'm sure there's
something for utc to synchronize the system with the hardware clock.
Yes, it's # hwclock --systohc --utc

[Lew Pitcher]

[snip]

Post by Jimmy Johnson

Post by Lew Pitcher
So, a cautionary note: the glibc-zoneinfo-2020b-noarch-1_slack14.0
upgrade changed something radically. If you run 14.0, check that your
timezone data still applies properly after the upgrade.

The slackware system still works, but sometimes system installers get
things backwards and now you find a upgrade can screw things the wrong
way too. I multi-boot and just one system can screw them all.

I no longer run Microsoft Windows, so my experience is out of date, but...
It used to be that Microsoft Windows expected the hardware RTC to be set
to localtime. Slackware's startup (rc.S) checks the contents of
/etc/hardwareclock to determine if the RTC is set to UTC or localtime,
and executes the appropriate hwclock command to retrieve the value and
set the Unix system clock. So, yes, multibooting can be a pain,
especially as you have to accomodate Windows quirks.

Post by Jimmy Johnson
I set the
hardware clock, boot the system, set the local, set the time and run #
hwclock --systohc --localtime.

You shouldn't have to do that manually; check the contents of Slackware's
/etc/hardwareclock, and run timeconfig to set it properly

Post by Jimmy Johnson
Sorry I don't use utc,

Understandable, given that you multiboot.

Post by Jimmy Johnson
I'm sure there's
something for utc to synchronize the system with the hardware clock.
Yes, it's # hwclock --systohc --utc

Correct

[Jimmy Johnson]

Post by Lew Pitcher

Post by Jimmy Johnson

Post by Lew Pitcher
So, a cautionary note: the glibc-zoneinfo-2020b-noarch-1_slack14.0
upgrade changed something radically. If you run 14.0, check that your
timezone data still applies properly after the upgrade.

The slackware system still works, but sometimes system installers get
things backwards and now you find a upgrade can screw things the wrong
way too. I multi-boot and just one system can screw them all.

I no longer run Microsoft Windows, so my experience is out of date, but...
It used to be that Microsoft Windows expected the hardware RTC to be set
to localtime. Slackware's startup (rc.S) checks the contents of
/etc/hardwareclock to determine if the RTC is set to UTC or localtime,
and executes the appropriate hwclock command to retrieve the value and
set the Unix system clock. So, yes, multibooting can be a pain,
especially as you have to accomodate Windows quirks.

I test linux systems that are without systemd, old school linux using
current desktops and applications. I'm currently testing one that has no
systemd installed at all, no libsystemd, no shim and I have it running
plasma5 with sddm. No windows running here since 2002, I made my living
doing warranty repairs on windows and apple systems up to 2017, one of
my tools was a small win98 laptop with 32mb ram and puppy installed, I
mostly used it for troubleshooting network setups, and then spine and
nerve damage caused my retirement ending the work I enjoyed doing. When
not testing other linux systems, I go to Slackware for a break, I love
the dependable peace I get using slackware and it's so good the way it
lowers my high blood pressure. :)

[Lew Pitcher]

Post by Lew Pitcher
I run 32bit Slackware 14.0 on one of my systems, and apply relevant
patches from Slackware when they become available. This afternoon, I
applied (using upgradepkg) the recent glibc-zoneinfo-2020b-
noarch-1_slack14.0 the over an existing (and working) glibc-
zoneinfo-2020a-noarch-1_slack14.0.

[snip]

Post by Lew Pitcher
So, a cautionary note: the glibc-zoneinfo-2020b-noarch-1_slack14.0
upgrade changed something radically. If you run 14.0, check that your
timezone data still applies properly after the upgrade.

Followup:

I used zdump to dump both the 2020a and 2020b versions of the EST5EDT zic
file.

The 2020a version decoded to 302 lines:
~/tmp $ /usr/sbin/zdump -v /usr/share/zoneinfo/EST5EDT |wc -l
302

The 2020b version (unpackaged into ~/tmp using explodepkg) decoded to 4
lines:
~/tmp $ /usr/sbin/zdump -v ./usr/share/zoneinfo/EST5EDT |wc -l
4

A similar dump of the EST5EDT packaged in glibc-zoneinfo-2020b-
noarch-1_slack14.2 gives 2150 lines
22:36 $ /usr/sbin/zdump -v /usr/share/zoneinfo/EST5EDT | wc -l
2150

So, definitely something not right with the EST5EDT zic file in
glibc-zoneinfo-2020b-noarch-1_slack14.0

[Henrik Carlqvist]

Post by Lew Pitcher
I immediately suspected the 2020b zoneinfo update, and reversed it out
(reapplying via upgradepkg the glibc-zoneinfo-2020a-noarch-1_slack14.0
patch.

During the years I have learned to avoid to apply the glibc-zoneinfo
patches. It seems as if the timezone configurations done at the end of
the Slackware installations by the script /var/log/setup/setup.timeconfig
might get lost when applying a glibc-zoneinfo patch.

However, I have never had any problem with my custom installation scripts
which on new installs first applies all patches including the glibc-
zoneinfo patches and then runs the configuration scripts including the
/var/log/setup/setup.timeconfig

So my recently installed machines gets the latest glibc-zoneinfo patches
and my older installation keep their older glibc-zoneinfo. So far that
has worked for me as I have lived in a location with constant daylight
saving and time zone settings.

regards Henrik

[Lew Pitcher]

Hi, Henrik

Post by Henrik Carlqvist

Post by Lew Pitcher
I immediately suspected the 2020b zoneinfo update, and reversed it out
(reapplying via upgradepkg the glibc-zoneinfo-2020a-noarch-1_slack14.0
patch.

During the years I have learned to avoid to apply the glibc-zoneinfo
patches. It seems as if the timezone configurations done at the end of
the Slackware installations by the script
/var/log/setup/setup.timeconfig might get lost when applying a
glibc-zoneinfo patch.
However, I have never had any problem with my custom installation
scripts which on new installs first applies all patches including the
glibc- zoneinfo patches and then runs the configuration scripts
including the /var/log/setup/setup.timeconfig
So my recently installed machines gets the latest glibc-zoneinfo patches
and my older installation keep their older glibc-zoneinfo. So far that
has worked for me as I have lived in a location with constant daylight
saving and time zone settings.
regards Henrik

I checked the install script that comes with the timezone patch, and it /
tries/ to "do the right thing" in retaining existing timezone settings.
But, we each customize our systems to our own liking, and perhaps the
script isn't as comprehensive as it might be.

It's probably wise to exercise a "if it isn't broke, don't fix it"
approach to the system, especially if you aim for stability, and timezone
file changes rarely affect our systems (mostly, we aren't in the timezone
that changed, and so can ignore timezone changes).

My only excuse is that I had already applied the timezone package change
to two other systems without impact; I had no expectation that it would
negatively affect my (admittedly backlevel) Slackware 14.0 installation.

I now know better.

[Lew Pitcher]

On Mon, 12 Oct 2020 01:06:11 +0000, Lew Pitcher wrote:

[snip]

Post by Lew Pitcher
So, a cautionary note: the glibc-zoneinfo-2020b-noarch-1_slack14.0
upgrade changed something radically. If you run 14.0, check that your
timezone data still applies properly after the upgrade.

So, a followup...

Timezone files contain either 1 or 3 sections, depending on a version
code embedded in the 1st section. "Old style" one-section (version 0x00)
timezone files encode key times and time adjustment values as 32bit
integers, making them susceptable to the Unix Y2038 32bit time overflow/
rollover problem.

The newer, 3-section, style of timezone file (version 0x32) attempts to
fix the Y2038 exposure of the "old style" format by adding second section
that contains 64bit key times and time adjustment values. In operation,
there are two varieties of this style of timezone file: a "fat" version
in which the first (32bit times) section is kept in sync with the second
(64bit times) section, and a second variety (a "thin" version) which
fills in the first section with dummy values (which look like the UTC
settings), and depends entirely on the values in the second section.

Prior to the 2020b versions of the timezone files, the upstream default
was to encode the files in the "fat" format (maintaining both backwards
and forwards compatability); from 2020b onwards, the upstream default is
the "thin" format (breaking backwards compatability).

With the release of glibc-zoneinfo-2020b-noarch-1, Slackware's supplied
timezone files had the "thin" format; prior to that, they were the "fat"
format.

It /appears/ that glibc 2.15 (the glibc that Slackware supplies with
Slackware 14.0) only parses the first (or 32bit) section of the timezone
file, while later versions of glibc default to the second (or 64bit)
section.

So, when I applied glibc-zoneinfo-2020b-noarch-1 to my Slackware 14.0
system, the 14.0 glibc (v 2.15) only looked at the first section of the
(now) "thin" timezone file, and found only UTC values.

Note that, when I applied glibc-zoneinfo-2020b-noarch-1 to my Slackware
14.2 systems, I had no timezone issues, implying that the glibc v2.23
that Slackware supplies for 14.2 had defaulted to processing the second
(64bit) section.

I note that, in Monday's changelog, Pat has reissued the
glibc-zoneinfo-2020b package, defaulting it to the "fat" format that is
backwards-compatible with older glibc versions. I don't yet know if he
has reissued the 2020b package for the other supported Slackware releases
yet.

In the future, he might revert to the "thin" format, once he expires
support for the older glibc versions that require the "fat" format.

[Henrik Carlqvist]

Post by Lew Pitcher
I note that, in Monday's changelog, Pat has reissued the
glibc-zoneinfo-2020b package, defaulting it to the "fat" format that is
backwards-compatible with older glibc versions. I don't yet know if he
has reissued the 2020b package for the other supported Slackware
releases yet.

At the time of this writing there is a new package also for your
Slackware 14.0, from
ftp://ftp.osuosl.org/pub/slackware/slackware64-14.0/ChangeLog.txt :

-8<-----------------------
Mon Oct 12 18:55:06 UTC 2020
patches/packages/glibc-zoneinfo-2020b-noarch-2_slack14.0.txz: Rebuilt.
Default to more bloated (but more compatible) "fat" format with zic.
This was the default prior to tzcode2020b.
-8<-----------------------

I was burned once a long time ago and now avoid the glibc-zoneinfo
patches, but maybe the installscripts nowadays work better in avoiding
reverting choosed settings.

regards Henrik