I can think of a third way to combat that problem: make the code that reads the data files robust, so it checks for invalid data and makes sure it can never crash due to bogus data. I just added code to the GNU libc tz implementation to do this. It took me about five minutes, and the added run-time overhead is not much given what's already going on to internalize the data file. It is a matter of security policy how you want to restrict the setting of the TZ variable. I wouldn't want it restricted at all. Why shouldn't I use my own timezone data files? It's certainly the easiest way to test new data files before installing them to point TZ at my own data files and run `date'. I prefer policies based on content rather than origin. It is a matter of local administrative quality whether the installed data files are more or less likely to contain valid or correct data than ones a user maintains himself. If the intent is to avoid crashing programs, robust reading code is protected against both mistakes and malice, whether installed system-wide or self-inflicted by the individual user. If the intent is to administratively restrict the time zones users can ask for display in, then all you have succeeded in doing is forcing people to use the cryptic 1003.1 TZ syntax instead of writing their own wonderful zoneinfo files through the joys of zic.