While I agree that setting TZ in the environment is best used for a user modification of the default, you have to admit that an implementation that read /etc/timezone every time you did an ls -l or called ctime for logging would be awfully slow. Not really. I tested Arthur Olson's code, which doesn't read "/etc/TIMEZONE" but *does* read a file of rules, with a program that just converted the current time using "ctime". The difference in time was negligible. It probably took more time to load the test program(s) than it took to read the files - and this was a version that read files that were written with a machine-independent byte order; it wasn't just doing one big "read". Even using Sun XDR, it wasn't a major difference. (Also, remember that a program won't read "/etc/timezone", or the setup files, *every* time it calls "ctime"; once is enough. Yes, this means you have to restart long-running programs if the rules change, but that shouldn't happen too frequently.) This is why I liked the ftime system call notion; it's impossible to forge, easy to default, easy to configure, and fast. Unfortunately, it's also incomplete, unless you extend "ftime" to return a table of DST on/off times. Recompiling every program that uses "ctime" because the U.S. Congress extended DST is a pain; it's worse in countries that seem to change the rules on a yearly basis....