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@eskimo.com