Well, once again the ignoramuses (ignoramii?) in Congress have managed to pass yet another brilliant piece of legislation. It seems that as part of the Energy Policy Act of 2005, the beginning and ending dates of daylight savings will change effective March of 2007. This obviously creates a Y2K-esque problem for operating systems that automatically adjust the system time to account for the change.
As a long-time computer hobbist, I--like many others--maintain an extensive home network of legacy computers and computer-like gadgets that run a wide variety of operating systems. I've had to spend a fair amount of time researching the DST issue for the various operating systems, and I'm posting my findings here for anyone that may benefit.
If you have additional information, or information that is contrary to what is posted here, please e-mail me at jlanter (at) lanteronline (dot) com.
I haven't been able to make any determinations about this yet.
I haven't been able to make any determinations about this yet.
I haven't been able to make any determinations about this yet.
No changes are necessary. See Microsoft MS-DOS below.
The following is excerpted from a post by Carl Gehr on news.ecomstation.com:
As a veteran of the Y2K wars, I did some investigation into the OS/2 implications and came up with the following that I BELIEVE to be true, but have not completely validated:
There is a SET TZ statement in the OS/2 Config.Sys. My interpretation of the fields results in the following:
The changes:
- Current/Pre-2007 Specification in OS/2:
SET TZ=EST5EDT,4,1,0,7200,10,-1,0,7200,3600
- DST-2007 Specification for OS/2:
SET TZ=EST5EDT,3,2,0,7200,11,1,0,7200,3600
Old values:
4,1,0: DST Starts in April, 1st week, on Sunday
10,-1,0: DST Ends in October, last week, on Sunday
New values:
3,2,0: DST Starts in March, 2nd week, on Sunday
11,1,0: DST Ends in November, 1st week, on Sunday
The '7200' is the time of day of the change in seconds = 2:00AM local time. The '3600' is the number of seconds to change = one hour.
I would have to assume that the above would also apply to Warp 3. Prior to that, however, I can't guess.
There are no APARs for v4.3 to address the DST issue. However, IBM has an excellent article that explains how to work around the problem by manually adjusting the time zone variable. Following is an excerpt from that article (note the similarity to OS/2 Warp 4 listed above):
If you wish to change the date or time at which the system switches to DST and back to Standard Time from the defaults for your zone, edit the TZ line in /etc/environment. Change the line to read something like the following:
TZ=CST6CDT,M3.2.0/2:00:00,M11.1.0/2:00:00The above example would effect a change to Daylight Savings Time at 2:00 AM on the second Sunday in March and change back at 2:00 AM on the first Sunday in November, and keep the US Central Time Zone time offset from GMT. The breakdown of the string is:
- CST6CDT is the time zone you are in;
- M3 is the third month;
- .2 is the second occurrence of the day in the month;
- .0 is Sunday;
- /1:00:00 is the time.
In more detail, the format is TZ = local_timezone,date/time,date/time. Here date is in the form of Mm.n.d, day d(0-6) of week n (1-5, where week 5 means "the last d day in month m" and which may occur in either the fourth or the fifth week) of month m of the year. Week 1 is the first week in which the day d occurs. Day zero is Sunday. This format is compliant with POSIX 1003.1 standards for Extensions to Time Functions.
NOTE: This can be changed in the smit chtz panel as well.
There are APARs available for the various 5.x versions that address the issue, although some of the prerequisites are rumored to be faily large. Search the IBM website to find them. Alternately, the information given above for AIX v4.3 also applies to 5.x.
Versions of Windows based on the Windows NT kernal store basic timezone data under the following registry key, which is referred to as the "timezone database":
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time
Zones
Another registry key contains the configuration data for the time zone that is in use by the current Windows control set. Windows copies this information from the time zone database when a time zone is selected in the control panel (note, however, that the format of the two hives is different.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
A cursory inspection suggests that the timezone database hive and the current controlset timezone hive are essentially the same for all versions of Windows that derive from NT (prior to Vista). However, the names of timezones have occasionally changed between different versions of Windows, so the specific key names in the timezone data hive may differ between versions.
Microsoft provides a tool called TZEDIT
that is a"nice" way of manipulating the time zone information stored
in the timezone database without having to hack the registry directly.
Using this tool you can modifiy time zone data for individual time zones
in the timezone database. Once the desired time zone has been edited,
re-select it in the control panel in order to copy the data to the current
control set.
Better still, Microsoft Knowledge Base article
KB914387 gives steps to create a registry
file that can be imported to the registry and that will create all new
time zones. You may want to first delete the entire Time Zones
hive first, to avoid creating duplicate timezones. Again, once the
registry file has been imported, re-select the desired time zone in the
control panel in order to copy the data to the current control set.
Before reading this section, please read the previous section pertaining to versions of Windows derived from Windows NT, as much of the information is similar.
Versions of Windows based on Windows 95 store basic timezone data under the following registry key, which is referred to as the "timezone database" note that this is slightly different than for versions derived from Windows NT:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Time
Zones
As with versions derived from Windows NT, the Windows 95 versions store information about the time zone that is in use by the current Windows control set under the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
Unfortunately, the TZEDIT tool will not run on these versions
of Windows. However, with some minor modifications, a modified version of the registry file for
Windows NT versions can be used on Windows 95 versions. The modifications
are just a few lines at the beginning of the file that enable the older
versions of REGEDIT to import the file.
Not sure about this yet... need to fire up my Windows 3.11 box....
No changes are necessary. MS-DOS did not keep track of the time or the
date, and as such it made no adjustments for daylight savings. the MS-DOS
commands DATE and TIME simply interacted with
the system BIOS to read or set the system clock.
As far as I can tell from reading the support section of the Palm website, all versions of the PlamOS v 4.x and prior needed to be manually adjusted twice per year to account for daylight savings. Since there is no automatic switching, there is no issue and no patch is needed.
There are updates for Palm OS v5.x and later available for download from the Palm website. Palm recommends you deal with your PC operating system first, before applying the updates.
I haven't been able to make any determinations about this yet.