Changes to Daylight Saving Time in 2007:

 Currently, daylight time begins in the United States on the first Sunday
 in April and ends on the last Sunday in October. On the first Sunday 
 in April, clocks are set ahead one hour at 2:00 a.m. local standard 
 time, which becomes 3:00 a.m. local daylight time. On the last Sunday 
 in October, clocks are set back one hour at 2:00 a.m. local daylight 
 time, which becomes 1:00 a.m. local standard time. These dates were 
 recently modified with the passage of the Energy Policy Act of 2005, 
 Pub. L. no. 109-58, 119 Stat 594 (2005). Starting in March 2007, 
 daylight time in the United States will begin on the second Sunday 
 in March and end on the first Sunday in November.



MXG Software code is impervious to Daylight Savings Time; we give you
the data that is in your RMF,SMF, etc. data, as you choose to create it.

If you choose to set your clocks back on an active system, you corrupt
many datetime values (i.e, jobs end before they start, negative elapsed
times, intervals end times before their begin time, etc.), and you will
create multiple records with the same STARTIME in all RMF datasets, as
well as CICINTRV, SMFINTRV, and any other interval datasets, but that's
the result of your choice to set back clocks on an active system, and
not of MXG's doing.  If the  records also contain an actual GMT Offset
field, those pairs of same-STARTIME observations can be identified, but
your hourly reports for the hour of time setback will have
pseudo-duplicate data.

MXG Change 24.224 (in MXG 24.09) for the ASUM70PR summarization example
now protects the TYPE70PR RMF data so that those pseudo-duplicates are
summarized as separate observations, with different GMTOFFTM values, but
with the same STARTIME values, i.e., you still have duplicate STARTIME
values in your data.

Note that if your installation uses the TIMEBILD architecture (to tell
MXG to change all datetime variables from SYSTEM's that are on different
time zones to a common timezone), as long as you correctly update the
mapping table in advance of the time change, MXG will correctly handle
each system's time change, but, again, if you choose to set clocks back
on an active system, all of the preceeding caveats apply.

It is precisely when you have local time as a result of the GMT Offset
that you are exposed to errors if you change the time (i.e., change the
GMT Offset) backwards on an active system.  If you have a GMT Offset of
zero, and you keep all your clocks on GMT, there there is no change in
your timestamps.

This information was posted to our MXG-L ListServer in Dec, 2006.

Herbert W. "Barry" Merrill, PhD
President-Programmer
MXG Software
Merrill Consultants
10717 Cromwell Drive
Dallas, TX 75229
www.mxg.com