[Bug time/28707] New: assert in tzfile.c __tzfile_read striking with truncated timezones generated by tzcode-2021d and later

["hp at sourceware dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28707

            Bug ID: 28707
           Summary: assert in tzfile.c __tzfile_read striking with
                    truncated timezones generated by tzcode-2021d and
                    later
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: time
          Assignee: unassigned at sourceware dot org
          Reporter: hp at sourceware dot org
  Target Milestone: ---

Created attachment 13858
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13858&action=edit
git patch with test-case

When using a timezone file generated by the zic in IANA
tzcode-2021d a.k.a. tzlib-2021d (also in tzlib-2021e; current as
of this writing), glibc asserts in __tzfile_read (on
e.g. tzset() for this file) and you may find lines matching
"tzfile.c:435: __tzfile_read: Assertion `num_types == 1' failed"
in your syslog.

Attached is a test-case including the tzfile for Asuncion
generated by tzlib-2021e as follows, using the tzlib-2021e zic:
"zic -d DEST -r @1546300800 -L /dev/null -b slim
SOURCE/southamerica".  Note that in its type 2 header, it has
two entries in its "time-types" array (types), but only one
entry in its "transition types" array (type_idxs).

This is valid and expected already in the published RFC8536, and
not even frowned upon: "Local time for timestamps before the
first transition is specified by the first time type (time type
0)" ... "every nonzero local time type index SHOULD appear at
least once in the transition type array".  Note the "nonzero ...
index".  Until the 2021d zic, index 0 has been shared by the
first valid transition but with 2021d it's separate, set apart
as a placeholder and only "implicitly" indexed.  (A draft update
of the RFC mandates that the entry at index 0 is a placeholder
in this case, hence can no longer be shared.)

So, unless glibc is specifically intended only to be used with
timezone-files generated by its own zic (an older version of the
tzcode zic), as opposed to e.g. timezone-files generated by
current (IANA) tzcode otherwise following RFC8536, the assert is
invalid.

-- 
You are receiving this mail because:
You are on the CC list for the bug.