UNIX for Dummies Questions & Answers

Yes, the "related system"...is running the same OS.
The OS is quite old - UnixWare 1.1

I found an explanation for the odd value of the TZ variable.
Turns out this syntax is a characteristic of non-POSIX TZ values;
for whatever reason the leading colon needs to be there.

If the TZ does not have the leading colon, the expression is ignored and I simply get GMT (which does not manifest the 'at' problem). If the TZ value does have the leading colon (and thereby impacts the system time) I will get the incorrect 'at' behavior.

Hmmm... a standard for non-standard systems. That's deep.

That is actually the System V release 4 version of TZ. I have been referring to the SunOS man page which documents the colon. But I had trouble understanding it. Now I have looked at the man page for your system. It looks like Sun tweaked the TZ concept a little (big surprise there) and didn't update the man page well. Now I finally understand that colon. You can ignore my second suggestion in my previous post. I now modify it to:
TZ=:US/Eastern
However according to your man page that would behave identically to TZ=:/usr/lib/locale/TZ/US/Eastern
which is what you have.

It looks like you have a zdump. Did you try that?

Sorry for the delay - I couldn't get access to the system for a few days.
I retried stuff again and the output is appended below.
If you have an epiphany that makes sense out of this, I'd be most obliged.
Thanks, in any event, for your responses and attempts to help.
---------------------------------------
---------------------------------------
Final summary ....

CASE 1: TZ=:US/Eastern
------------------------
Basically if TZ is defined such as ":US/Eastern" then `date` works fine,
but the `at` command is scheduled exactly 2 hours late.
Zdump cannot resolve the ":US/Eastern" syntax.
Note that after it says it cannot find ":US/Eastern" it seems to print out
the time as GMT.

btd33m01!root[10] env - /usr/bin/ksh
# env
_=/bin/env
PWD=/
# export TZ=:US/Eastern
# date
Wed Aug 3 15:35:41 EDT 2005
# /usr/sbin/zdump -v -c 2007 $TZ | tail
/usr/sbin/zdump: Can't open :US/Eastern: No such file or directory
:US/Eastern Wed Aug 3 19:36:54 2005

CASE 2: TZ=US/Eastern
------------------------
If TZ is defined without the colon, i.e. "US/Eastern" then `date` is wrong.
The time is reported as GMT - the same as if TZ is not defined.
However, the `at` symptom disappears - any job scheduled is
set to the appropriate GMT time, with no 2 hour discrepancy.
And zdump happily parses the TZ, whether defined as "US/Eastern"
or as "/usr/lib/locale/TZ/US/Eastern"

Code:

btd33m01!root[12] env - /usr/bin/ksh
# pwd
/
# date   
Wed Aug  3 19:44:10 GMT 2005
# echo $TZ

# export TZ=US/Eastern
# date
Wed Aug  3 19:44:36 GMT 2005
# /usr/sbin/zdump -v -c 2007 $TZ | tail 
US/Eastern  Sun Apr  3 06:59:59 2005 GMT = Sun Apr  3 06:59:59 2005 isdst=0 gmtoff=0
US/Eastern  Sun Apr  3 07:00:00 2005 GMT = Sun Apr  3 07:00:00 2005 isdst=0 gmtoff=0
US/Eastern  Sun Oct 30 05:59:59 2005 GMT = Sun Oct 30 05:59:59 2005 isdst=0 gmtoff=0
US/Eastern  Sun Oct 30 06:00:00 2005 GMT = Sun Oct 30 06:00:00 2005 isdst=0 gmtoff=0
US/Eastern  Sun Apr  2 06:59:59 2006 GMT = Sun Apr  2 06:59:59 2006 isdst=0 gmtoff=0
US/Eastern  Sun Apr  2 07:00:00 2006 GMT = Sun Apr  2 07:00:00 2006 isdst=0 gmtoff=0
US/Eastern  Sun Oct 29 05:59:59 2006 GMT = Sun Oct 29 05:59:59 2006 isdst=0 gmtoff=0
US/Eastern  Sun Oct 29 06:00:00 2006 GMT = Sun Oct 29 06:00:00 2006 isdst=0 gmtoff=0
US/Eastern  Mon Jan 18 03:14:07 2038 GMT = Mon Jan 18 03:14:07 2038 isdst=0 gmtoff=0
US/Eastern  Tue Jan 19 03:14:07 2038 GMT = Tue Jan 19 03:14:07 2038 isdst=0 gmtoff=0

None of that really helps very much.
TZ=US/Eastern
TZ=sjssjjdjdjdeerr
and TZ=any-other-illegal-string
should all give the same results. What happened to case zero (TZ=:/usr/lib/locale/TZ/US/Eastern )? All three commands should find your zone file if you use that. Your zdump of the default GMT timezone file doesn't tell me much. Your at command works when you use it. It's the other timezone file that I think is screwy. In the SunOS source code for at.c, the last operation done on the constructed time is:
if (localtime(&when)->tm_isdst) when -= (timezone-altzone);

Your case 1 does suggest that the commands themselves may be at different rev levels. Have you compared the executables between the systems that work and the systems that fail? This is a new symptom that may or may not be related to the misbehavior when you use TZ with a full path. But to look at this... you might have a file /usr/include/tzfile.h that defines a constant called TZDIR. See if you can find the value of that constant.