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