[Discussion] New Daylight Savings Time Changes [Was: ECS- Eliminate excess Printers]

[Carl Gehr]

On Mon, 22 Jan 2007 11:24:36 -0800 (PST), Jon Harrison wrote:

>
>In this regard, you say:
>
>"The TZ variable should be set to something like this:
>SET TZ=PST8PDT
>But the eCS clock program sets it to something like:
>SET TZ=PST8PDT,4,1,0,7200,10,-1,0,7200,3600"
>
>It will be interesting on March 11th to know whether or not your
>clock responds properly to Daylight Savings Time.
>
>Jon

Jon,

I believe the expanded SET TZ that you show is not correct.

First, here's the actual rule changes taken from an IBM FAQ document:
>         Daylight Saving Time (DST) Frequently Asked Questions:
>         Tuesday, November 14, 2006
>
>   Q1. What caused the need to change the Daylight Saving
>   Time rules for our hardware and software products?
>
>   A1. In the U.S., the Energy Policy Act of 2005 changed the
>   rules for Daylight Saving Time (DST).  These new rules
>   will go into effect in March 2007. Canada and Bermuda made
>   similar changes to their DST rules to be consistent with
>   the U.S. time changes. DST rules affect date and time
>   processing functions in computers and applications. If not
>   set properly, the time could be incorrect by one hour for
>   four weeks each year. Since DST rules have been relatively
>   stable in these countries for many years, people have come
>   to rely upon automated adjustments in time in connection
>   with their information technology. In order to support the
>   new DST schedule, updates to affected IBM hardware and
>   software are being provided.
>
>   Q2. What are the new dates for the Daylight Saving Time
>   schedule in the U.S., Canada and Bermuda?
>
>   A2. Starting in 2007, Daylight Saving Time for the U.S.,
>   Canada and Bermuda will be extended by four weeks,
>   starting three weeks earlier on the second Sunday in March
>   and ending one week later on the first Sunday in November.
>   In 2007, DST will start on Sunday, 11 March and will end
>   on Sunday, 4 November.
Ref for full FAQ document:
> http://www.ibm.com/support/alerts/us/DST_FAQ_11-14-06.pdf

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:

*  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

The changes:
    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.

It is possible that there are also applications that request the TOD
and then manipulate it, maybe using logic that is in the application to
deal with DST changes.  This is where 'DST2007' [the keyword that IBM
is using to search for these issues] is similar to Y2K.  If you think
you have such applications, you must find the requests, code, etc., and
evaluate and/or repair the code.

This change should handle system and application uses that simply
request the current time of day [TOD].  If there are others out there
[and I'm sure there are] who know more about the OS/2 time and TZ
processing, I hope they will speak up and correct any errors in my
evaluation.

We are reminding our customers [IBM Mainframe users] that the same
package that we provided for them to use for Y2K can be used to
investigate DST2007 issues in their applications.

[FWIW, I've heard that M$ has released a 'fix' for WindozeXP, but has
no plans to do the same for Win2K or earlier systems.  They have been
criticized by some members of the trade press for refusing to fix older
versions of Windoze.]

Carl