RE: Daylight Saving Time

[Bruce Vining <bvining@xxxxxxxxxx>]

I should clarify my earlier statement "It is because of these types of
headaches that the system internally tracks
time with UTC (rather than local time) starting with V5R3."

When you install V5R3 (or later releases) the internal time of day clock on
the system is changed to run on UTC.  Previous to V5R3 this time of day
clock always ran in local system time.  For compatibility reasons all
pre-existing interfaces to this clock where changed to automatically
convert from UTC to the local system time, and new interfaces provided
(like MI instructions MATTOD option x'0004' and  MATTODAT; API Retrieve
System Time Information (QWCRTVTM); etc) to access the UTC time tracked by
the system time of day clock.  Just like how application developers over
time will hopefully start using the UTC interfaces, so too over time i5/OS
developers will start using more of the underlying UTC support of the
system.  In the current releases QHST has not changed to a UTC base, but as
I mentioned in an earlier note I wouldn't be surprised to see this happen
at some future point.  The same would be true of all the other places in
the system (and there are LOTS if you think about it - commands; outfiles;
database fields of time, date, timestamp; APIs; panels; server
functions;,...) that work with time.  This change is obviously a major
effort in that it essentially means any input or output of time values
needs to be converted to/from UTC and the preferred local time of the user.
And you might notice in V5R3 that there is a read only job attribute for
time zone of the job (currently always set to the system time zone) which
is really suggestive...  I will point out that in the recently announced
V5R4 this is still read only.

So while the system is indeed internally tracking time with UTC, that
doesn't necessarily mean all parts of the system are internally working
with UTC (yet :) )

Bruce Vining (speaking only for myself)



                                                                           
             Scott Klement                                                 
             <midrange-l@scott                                             
             klement.com>                                               To 
             Sent by:                  Midrange Systems Technical          
             midrange-l-bounce         Discussion                          
             s@xxxxxxxxxxxx            <midrange-l@xxxxxxxxxxxx>           
                                                                        cc 
                                                                           
             02/01/2006 12:26                                      Subject 
             PM                        RE: Daylight Saving Time            
                                                                           
                                                                           
             Please respond to                                             
             Midrange Systems                                              
                 Technical                                                 
                Discussion                                                 
             <midrange-l@midra                                             
                 nge.com>                                                  
                                                                           
                                                                           





> Does that mean UTC is what goes into QHST?  Does that mean if I view
QHST,
> then change my time zone or offset, then view QHST again, the times will
be
> different?

That seems to be what he's saying (though I haven't tested it.)  I know
that this is the way the dates/times in the IFS work.


> And how does the Advanced Job Scheduler know not to run that 1:30am
> scheduled job a 2nd time?  Or does it run again?  (No, I don't have any
> between 1am and 3am, but inquiring minds want to know.)

Again, I haven't tested it, but according to what Bruce is saying, it
shouldn't have a problem.  You're thinking in local time, and that's why
you're thinking that 1:30 occurs twice.  In UTC time it does not.

Where I live (Central time zone) the standard time is -0600 from UTC.
Daylight savings is -0500 from UTC.

So if I schedule a job for 1:30, the system says "hmmm... he's 5 hours
earlier than UTC. So I'll schedule that job for 6:30 UTC".  When the
scheduler is running jobs, it's using that UTC time which doesn't change.
When 1:30 rolls around the first time, it's 6:30 UTC because it's still
daylight savings time.  When 2:00 comes, daylight savings ends and the
offset changes to -0600. My clock now says 1:00 local time, but the UTC
time is 7:00, which is later than 6:30.  When 1:30 rolls around it'll be
7:30 UTC...

At least I think that's what Bruce is saying.  (It doesn't completely make
sense, because then all of your job schedule entries will be an hour off
of what they originally were, which would cause a great deal of
confusion.)
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.