[tz] data not represented in tzfiles

[Paul Eggert]

Zefram wrote:

> I've posted a patch more than one that would make the
> 400 year hack more robust, and it seems to have got lost each time.
> It's sitting on a branch in my public git repo.

Sorry about that, it was still in my inbox.  I revisited it
today.  It inserts an artificial mark into the zic binary
file so that, for zones in which POSIX TZ strings cannot
support time stamps into the indefinite future, a consumer
of the binary file can more easily determine where its data
are valid.

This jogged my brain to look two other items in my inbox
that are relevant and less problematic.  I fixed these and
pushed the fixes into the experimental github.

First, "Record that San Luis is at UTC-3, not UTC-4 with perpetual DST."
<http://mm.icann.org/pipermail/tz/2013-September/019996.html>
adjusts Argentina/San_Luis to not have a weird setting of
perpetual DST indefinitely into the future, a setting that
POSIX TZ strings cannot represent.

Second, "Support time stamps past 2038 in zones like America/Santiago"
<http://mm.icann.org/pipermail/tz/2013-September/020013.html>
fixes zic to generate TZ strings that work into the
indefinite future for almost all zones where this was a
problem, thus removing the need for the artificial mark in
these zones.

There's one remaining zone which has the problem, namely
Asia/Tehran, but I don't think your 400-year change fixes
it.  So, I'm hoping that your fix is no longer needed, in
that the other two patches have fixed things in a different way.

Anyway, thanks for bringing this up, as it prompted fixes
for the problems in the database or the way it's processed
on POSIX platforms.