[tz] tzcode error handling

[Zefram]

Steve Summit wrote:
>Patch 1 optionally prints some simple, straightforward error
>messages if a requested zone can't be loaded.

Emitting human-orineted messages is a crap way for library code to
signal an error.  It means the calling code has no opportunity to handle
the error in a manner coherent with its own requirements and style.
You at least get points for giving the caller control over where the
message goes, but the global variable controlling error disposition
breaks code composability: an innocent application utility function that
used to internally perform a time conversion now acquires the additional
externally-visible behaviour of emitting unwanted warnings, because the
top-level program wants the warnings for its own time conversions.

There is already a defined way for localtime() et al to report an error:
they can return NULL.  This doesn't give much information, but at least
the caller can see that there was an error on that specific call.  If you
want to declare some situation to be an error, this is the place to start.
If that would break too much existing code, then surely emitting warning
messages under control of a new mechanism that existing code doesn't
know about would also be too breaking.

The better way to signal errors would be to fill a somewhat-user-parseable
structure describing the error, and to return it as an additional result
from the call that incurred the error, with the caller having requested
this kind of information for that specific call.  This implies calling
a new API function instead of the existing ones.  This would be better
applied to any of the proposed APIs that pass more of the operands
explicitly, than to the legacy APIs that use global variables all over.

Of course one would provide a function to translate an error-describing
structure into a human-oriented message.  But think about locale for a
minute: this translation potentially varies based on locale, and this is
the right place for that locale to be decided.  One doesn't necessarily
want error messages in the same locale as the formatting of the time
string requested from strftime().  Give the caller control over this.

-zefram