FYI ...WE had some problems with ADSM and the time change on AIX 4.2.1/
server 2.1.5.13, so we upgraded to server 2.1.5.18 per IBM support to
fix daylight savings time error
This mail message is a bit old, just looking through some of the past
stuff you know....

> ----------
> From:         Jerry Lawson[SMTP:jlawson AT thehartford DOT com]
> Sent:         Wednesday, April 15, 1998 7:07 AM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Strange DST discovery
>
> Date:     April 15, 1998           Time: 7:17 AM
> From:     Jerry Lawson
>           The Hartford Insurance Group
> (860)  547-2960          jlawson AT thehartford DOT com
> ----------------------------------------------------------------------
> -------
> I suppose there's a logical expatiation for what I just saw this
> morning, but
> it escapes me at the moment.....
>
> I was poking through my Sequential Volume History log this morning,
> looking
> at the DB backup tape history, and I noticed that backup events
> scheduled for
> 6:00 AM were being reported as starting at 7:00 AM.  Then I realized
> that
> these were the older entries in the log (prior to 4/5) - the ones
> after 4/5
> were correct (started at 6:00).  The only explanation I can come up
> with is
> that times are being reported as Daylight savings time events, even
> though
> they occurred when we were on standard time (or is that daylight
> wasting
> time?)!
>
> I would have expected that the actual local time of the event would
> have been
> recorded - not the time according to GMT.  This means that when the
> date is
> given in a report, the time must be recalculated for each event - in
> other
> words - GMT plus the local offset has to be applied!
>
> I checked this against both a V2 and a V3 admin. client, (GUI), and
> also a V3
> command line client, and the behavior was the same.  This would imply
> that
> the conversion is on the server (Which in my case is MVS V2 L13.
>
> The only explanation that I can see for this is the "fall back" to
> standard
> time - if GMT is stored, and then the time offset is applied,
> duplicate
> entries can't occur.  Is this the logic that was followed, or is there
> a
> different reason?  It also brings up some interesting questions - such
> as
> what happens to events that occurred in the hour after 11:00 PM
> (23:00) just
> prior to the DST change?  Were they reported as happening at 24:30,
> perhaps?
>
>
>
> ----------------------------------------------------------------------
> -------
>                                                      Jerry
>
> Insanity is doing the same thing over and over..and expecting the
> results to
> be different - Anon.
>