UNIX time and the parent environment

[Guy Harris]

>THE QUESTION: Why doesn't timelocal() use the environmental variable I'm
>manipulating?

Because you haven't told it to.

>Is there a way to get it to sit up and take notice?

Yes.  From the 4.0.1 CTIME(3) (presented out of order):

     "tzset()" uses the value of the environment variable TZ  to  set
     time  conversion  information used by "localtime()".

	...

     ..."timelocal()" converts a "struct tm" that represents local time,
     correcting for the time  zone and  any  time  zone  adjustments
     (such as Daylight Savings Time).  Before doing so, "timelocal()"
     calls "tzset()"  (if "tzset()" has  not been called in the current
     process).

The key part is "if 'tzset()' has not been called in the current
process".  Basically, "timelocal()" does not check TZ every time; by and
large, it assumes it's already been checked.  It only checks it if it
knows that it has not been checked. 

"tzset()" is the routine that actually checks TZ.  If you explicitly
call it, it throws out any data it constructed from any previous
invocation, and reconstructs it given the new setting of TZ.

I expect this to be true of any UNIX system with "tzset()", including
System V - no, System V, as currently distributed by AT&T, doesn't have
"timelocal()", but it *does* have "localtime()" (as anything worthy of
the name "UNIX" does), and "localtime()"'s behavior is also affected by
TZ.  Furthermore, S5R4 should have the ANSI C "mktime()" routine, which
is almost like "timelocal()", and which should be affected by TZ as
well.  (SunOS 4.1 should also have "mktime()"; since it's in the ANSI C
standard, it should in the future be used in preference to
"timelocal()".)

Thus, in any UNIX system supporting TZ (and, in fact, any POSIX
1003.1-compliant system, all of which must support TZ), a program should
call "tzset()" after changing TZ in the environment of the process in
which it's running.