date_time bugs after 2038, or with today's date and 'zic -b slim' TZif files
Glib date_time mishandles future time stamps, or even today's time stamps if given TZif files generated by the command
zic -b slim.
Since tzdb 2019b, the
zic command has had a
-b slim option that generates smaller-but-equivalent TZif files, intended to save memory/cache/whatever. These files conform to the TZif format specified in Internet RFC 8536 and are supported by tzcode, glibc, etc. and
-b slim is intended to be the default in future tzdb releases. However, the Glib TZif-file parsers mishandle slim TZif files.
This mishandling seems to occur because Glib gets confused about timestamps after the last explicit transition in a TZif file. For example,
zic -b slim generates a TZif file
Europe/Amsterdam where the last explicit transition is on 1996-03-31 and transitions thereafter are deduced from the
"CET-1CEST,M3.5.0,M10.5.0/3" string embedded at the end of the TZif file. Test cases involving current time stamps fail, I expect because this timestamp is after the last explicit transition.
Glib also mishandles timestamps past the last explicit transition even in traditional "fat" TZif files. For example, since the last transition in a traditional fat Europe/Amsterdam file is 2037-10-25, Glib mishandles some timestamps after that.
-b slim option becomes more popular this problem will affect Glib even for past and current timestamps, so the bug needs to be fixed now, rather than in 2038.
I'll attach a C source file that illustrates the problem on Fedora 31 x86-64 with traditional TZif files. Here's a shell transcript illustrating the Glib bug:
$ printf '%s\n' 2040-01-01 2040-07-01 | TZ=Europe/Amsterdam date -f- +'%s %Y-%m-%d %H:%M:%S %Z %z' 2208985200 2040-01-01 00:00:00 CET +0100 2224706400 2040-07-01 00:00:00 CEST +0200 $ gcc $(pkg-config --cflags glib-2.0) test-g_date_time_new_from_iso8601.c $(pkg-config --libs glib-2.0) $ TZ=Europe/Amsterdam ./a.out 2208985200 2040-01-01 00:00:00 CET +0100 2224710000 2040-07-01 00:00:00 CET +0100
The first pair of output lines (from the coreutils
date command) is correct. In the second pair, from Glib, the first line is correct but the second line is wrong: it incorrectly says that daylight-saving time will not be observed in Amsterdam in summer 2040.
A similar problem can be observed even in the year 2020, if Europe/Amsterdam was generated by
zic -b slim.