Let's say my system is still set up for last year's rule. My system will soon show the wrong time. What should I do? One thing that is
not a very good idea would be to crank the clock forward an hour manually. If I do that my system will have the wrong internal time. Some network based services such as NFS use the internal time. My system would also no longer have the correct Universal Time. NTP (Network Time Protocol) will malfunction and my system's clock will drift. Even for my own timezone, I would have timestamps like 17:00 EST when I should have 17:00 EDT. A few weeks later, the old rule will take effect and I will now need to adjust the clock manually again.
I hope that I have convinced you to not reset the time in this manner. One better option would be to research my system's data file that defines the daylight saving rules for my timezone and edit it myself. This should be a straight forward change. But each system may have its own format.
There does seem to be a near universal solution: use a more complex format for the TZ environment variable. You can actually put the Daylight Saving rule in TZ and this behavior is mandated by Posix. Below is a table of TZ settings that I believe to be correct for the year 2007.
Code:
# Posix Format
TZ="EST5EDT4,M3.2.0/02:00:00,M11.1.0/02:00:00" # US Eastern
TZ="CST6CDT5,M3.2.0/02:00:00,M11.1.0/02:00:00" # US Central
TZ="MST7MDT6,M3.2.0/02:00:00,M11.1.0/02:00:00" # US Mountain
TZ="PST8PDT7,M3.2.0/02:00:00,M11.1.0/02:00:00" # US Pacific
TZ="AST9ADT8,M3.2.0/02:00:00,M11.1.0/02:00:00" # US Alaska
TZ="HST10" # US Hawaii
# Old System V Release 3.1 and Xenix Format
TZ="EST5EDT4;M3.2.0/02:00:00,M11.1.0/02:00:00" # US Eastern
TZ="CST6CDT5;M3.2.0/02:00:00,M11.1.0/02:00:00" # US Central
TZ="MST7MDT6;M3.2.0/02:00:00,M11.1.0/02:00:00" # US Mountain
TZ="PST8PDT7;M3.2.0/02:00:00,M11.1.0/02:00:00" # US Pacific
TZ="AST9ADT8;M3.2.0/02:00:00,M11.1.0/02:00:00" # US Alaska
TZ="HST10" # US Hawaii