daylight savings time

[Doug Wilburn]

I have an Alpha 4100 running Tru64 5.1 (rev 732). I have edited /etc/zoneinfo/sources/northamerica with these changes...
# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
Rule US 1918 1919 - Mar lastSun 2:00 1:00 D
Rule US 1918 1919 - Oct lastSun 2:00 0 S
Rule US 1942 only - Feb 9 2:00 1:00 W # War
Rule US 1945 only - Aug 14 23:00u 1:00 P # Peace
Rule US 1945 only - Sep 30 2:00 0 S
Rule US 1967 2006 - Oct lastSun 2:00 0 S
Rule US 1967 1973 - Apr lastSun 2:00 1:00 D
Rule US 1974 only - Jan 6 2:00 1:00 D
Rule US 1975 only - Feb 23 2:00 1:00 D
Rule US 1976 1986 - Apr lastSun 2:00 1:00 D
Rule US 1987 2006 - Apr Sun>=1 2:00 1:00 D
Rule US 2007 max - Mar Sun>=8 2:00 1:00 D
Rule US 2007 max - Nov Sun>=1 2:00 0 S

Then recompiled with "zic northamerica".
When I "zdump -c 2008 -v America/Chicago", no change has taken place. The years 2007 & 2008 still show up as changing in April and October. I even downloaded ftp://elsie.nci.nih.gov/pub/tzcode2007c.tar.gz and recompiled with zic and get the same thing. What am I missing?

[Ivan Ferreira]

Do you have a line like:

# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone America/Chicago US

Somewhere in your zic file?

[Doug Wilburn]

Here is a section that looks like that...
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone America/Chicago -5:50:36 - LMT 1883 Nov 18 12:09:24
-6:00 US C%sT 1920
-6:00 Chicago C%sT 1936 Mar 1 2:00
-5:00 - EST 1936 Nov 15 2:00
-6:00 Chicago C%sT 1942
-6:00 US C%sT 1946
-6:00 Chicago C%sT 1967
-6:00 US C%sT

[Martin Moore]

Basic question -- did the file /etc/zoneinfo/America/Chicago actually get recreated when you ran zic? (Does it show a plausible timestamp with 'ls -l' ?)

Martin

[Doug Wilburn]

Yes - the America/Chicago file has a time stamp of when I compiled. I have done this to 3 of my other systems (Alpha's running Tru64 versions 5.1 (rev 732) and 5.1B (rev 2650) and it seems to have worked. Would it be of any value to take the America/Chicago file from one of those other systems and place it on this one? or take this "problem" America/Chicago and place it on another system that seemed to have worked and try the zdump command there? This really has me baffled.

[Martin Moore]

Yes, it's baffling to me as well, and I've seen the same procedure applied to literally hundreds of systems. Both of the ideas you suggest are worth a try, i.e., swapping the Chicago files between systems and see if you get the same results. Also checksumming the Chicago file on both the problem system and another V5.1 system would be good. You might want to do the same for /etc/zoneinfo/sources/northamerica; perhaps a stray character snuck in while you were editing it.

Martin

[Doug Wilburn]

I have swapped the northamerica files with other systems. When the northamerica file on the "not working" machine is moved to a "working" machine and recompiled, the zdump shows proper results. When a northamerica file on a "working" machine is moved to the "not working" machine and recompiled, the zdump results are the same as before (don't indicate the time change). I have gone to other servers now and have discovered that this problem is only occurring on my older machines that I haven't been able to update the OS. The two machines that this isn't working on are both running Tru64 5.1 (732). Other machines where this procedure is working are running newer ver's of Tru64, either 5.1A (1885) or 5.1B (2650). These older machines are running older app's that I'm not sure can take the upgrade.

[Martin Moore · Accepted solution]

I may have found the answer here. There was an update to zdump that first went in at V5.1 pk5. Do you know which patch kit you have installed? (If not, "dupatch -track -type kit" will tell you what's been installed.)

Among other things, the pre-fix version of zdump may display incorrect results when the timezone filename is NOT specified with a leading colon. Try the zdump command with the timezone specified as ":America/Chicago" rather than just "America/Chicago", and let's see if that works.

Regards,
Martin

[Doug Wilburn]

It hasn't been patched. It was a while back and evidently I didn't patch it upon installation.
However, the leading colon showed that my changes are there. I didn't do any edit or recompile - just entered the zdump command with colon and it indicates Mar. 11 and Nov. 4 time changes. Thanks alot.
By the way, I also noticed that my "locatime" is linked to ./US/Central. I assume I need to rm that link and relink to ./America/Chicago, correct? And, can that be done while the system has a user load?

[Martin Moore]

You can change the timezone on the fly without affecting anything:

# cd /etc/zoneinfo
# ln -sf ./America/Chicago localtime

US/Central and America/Chicago are supposed to be equivalent; in fact, they are usually hard links to the same file! However, I'm not sure where the hard link is defined in the zoneinfo source files at your version (I don't have one that old to check). If it's defined in northamerica, then zic would have recreated it. OTOH, if it's defined in /etc/zoneinfo/sources/backward (as it is on some other versions), then running 'zic northamerica' would break the hard link, but subsequently running 'zic backward' would restore it.

But in any case, the hard link issue becomes moot if you switch your localtime link to America/Chicago (which is the best solution, IMO.)

Martin