Arthur David Olson wrote:
It's probably worthwhile to check whether extended POSIX in zic-produced binaries will cause grief when those binaries are used with old versions of localtime.c. If so, one or more of documentation, a zic warning, or a version number bump may be in order.
Those suggestions sound good, and I'll soon propose a patch along those lines. I checked with the test script appended to the message, and it looks like we're pretty safe. The only problem I observed was with America/Godthab for dates past the start of 2038; this is because the new POSIX TZ string uses negative hours, which the old tz code does not grok. I doubt whether the Godthab issue is urgent, since we are talking only far-future dates here, and our predictions for them are quite possibly wrong anyway. export LC_ALL=C o=/tmp/tz-2013dd n=/tmp/tz omit_junk='s/^[^[:blank:]]*[[:blank:]]*//; s/ UTC / UT /' for zone in America/Los_Angeles Antarctica/Palmer Asia/Tehran Asia/Gaza Asia/Hebron Pacific/Fiji America/Godthab America/Argentina/San_Luis America/Santiago Pacific/Easter; do echo $zone report $o/etc/zdump -v $o/etc/zoneinfo-posix/$zone | sed "$omit_junk" >oo $o/etc/zdump -v $n/etc/zoneinfo-posix/$zone | sed "$omit_junk" >on $n/etc/zdump -v $o/etc/zoneinfo-posix/$zone | sed "$omit_junk" >no $n/etc/zdump -v $n/etc/zoneinfo-posix/$zone | sed "$omit_junk" >nn set oo on no nn for i in oo on no; do case $i in oo) js='on no nn';; on) js='no nn';; no) js='nn';; esac for j in $js; do diff -u $i $j done done done