Bug 10181 - tzset mishandles version 3 tzdb format
Summary: tzset mishandles version 3 tzdb format
Status: NEW
Alias: None
Product: uClibc
Classification: Unclassified
Component: Other (show other bugs)
Version: unspecified
Hardware: All All
: P5 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-07 16:26 UTC by Paul Eggert
Modified: 2017-08-07 19:14 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:


Attachments
untested patch to support tzdb version 3 files (2.02 KB, patch)
2017-08-07 16:26 UTC, Paul Eggert
Details
Patch revised to handle >2 digit hours (2.39 KB, patch)
2017-08-07 19:14 UTC, Paul Eggert
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Eggert 2017-08-07 16:26:16 UTC
Created attachment 7171 [details]
untested patch to support tzdb version 3 files

This bug report responds to the following thread on the tz mailing list:

http://mm.icann.org/pipermail/tz/2017-August/025205.html

The issue is that tzdb version 3 format extends version 2 slightly, in that the POSIX-style TZ strings at the binary-file's end are allowed to have start times that range from -167:59:59 to 167:59:59, instead of the POSIX-specified 00:00:00 through 24:59:59. This is needed to support the predicted future time zone settings for Israel and Western Greenland, which have the following TZ string values in current tzdb:

Asia/Jerusalem 'IST-2IDT,M3.4.4/26,M10.5.0'
America/Godthab '<-03>3<-02>,M3.5.0/-2,M10.5.0/-1'

Although POSIX currently does not require support for these strings, they are widely supported by other C libraries including glibc, and it should be easy to fix uClibc-ng to support them too. Proposed patch attached. I don't use uClibc so I have not tested it.
Comment 1 Paul Eggert 2017-08-07 19:14:43 UTC
Created attachment 7176 [details]
Patch revised to handle >2 digit hours

In rereading that patch I noticed that it allows hour counts only to 99, whereas it should be up to at least 167. While we're at it, let's just increase it to 254; that's just as easy. Revised (and still untested) patch attached.