[tz] tzcode error handling

[Steve Summit]

As mentioned in a previous message, tzcode's error handling
leaves a bit to be desired.  If you specify a nonexistent
timezone (say, by setting the TZ environment variable to it),
or if the tz files can't be found, or if you haven't specified
a time zone and the system's default tz file can't be found,
you quietly -- and I do mean quietly! -- get UTC instead.
There's no good way to know what went wrong.

I have some proposed patches to address this.  I'm presenting
this as a series of incremental patches, partly so that
interested readers can more easy follow the progression from
the current code to the fully modified, comprehensively error
reporting version, and partly because some of the later stages
might be thought too invasive for inclusion.

Patch 1 optionally prints some simple, straightforward error
messages if a requested zone can't be loaded.  The printing of
error messages is optional: library code obviously can't be
noisy, so the default behavior is the legacy, quiet fallback to
UTC.  Patch 1 also includes a (one line) change to the distributed
'date' command as a demonstration of how to enable verbose error
reporting.  For various reasons, though, the error messages go
only halfway: they can tell you that a zone couldn't be loaded,
but they can't always really tell you why.

So Patch 2 attempts to improve the error handling by printing
more useful messages.  For example, instead of printing
"Can't load zone America/New_York", it might say
"/usr/local/zoneinfo/America/New_York: No such file or
directory".  Unfortunately, this ends up requiring rather a lot
of changes, and the implementation is significantly imperfect in
that it uses some static global data which renders it non thread
safe in the error handling case.

Patch 3 refactors some code so that the relevant error reporting
information can be more cleanly preserved in the local_storage
structure, and for just long enough that the appropriate error
message can be generated without resorting to static data.
(The only remaining drawback is that I'm uncertain of the
interplay between these changes and the ALL_STATE option.)

Finally, patch 4 optionally prints some merely informative output
messages (e.g. "trying /usr/local/zoneinfo/EST5EDT", "parsing
'EST5EDT' as Posix tz string") which do not necessarily indicate
any error but which might be useful to maintainers.

The four patches are presented in the following four messages,
along with a certain amount of additional explanation.

This all seems to work, although I've seen a few spurious
warnings having to do with a missing and possibly optional
'posixrules' file.  I'm pretty sure those messages are due to
some misconfiguration in my test environments (and I'm pretty
sure the messages are innocuous, anyway), but if they crop up
for anybody else, they may need addressing.

					Steve Summit
					scs at eskimo.com