Sat Dec 20 12:44:03 UTC 1986
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
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....
More information about the tz