|
"Jeff Crosby" <jlcrosby@dilgard foods.com> To Sent by: "'Midrange Systems Technical midrange-l-bounce Discussion'" s@xxxxxxxxxxxx <midrange-l@xxxxxxxxxxxx> cc 02/01/2006 11:54 Subject AM RE: Daylight Saving Time Please respond to Midrange Systems Technical Discussion <midrange-l@midra nge.com> >> When DST starts local system time will change from 2:00 AM to >> 3:00 AM, and when ending from 2:00 AM to 1:00 AM. This will >> take place independent of whether or not you are using an >> external time server, and will conform to your local >> definitions of time. >I understood all that. I was looking for something that speeded it up to >move ahead an hour, or slowed it down for an hour catch-up instead of a jump >in one fell swoop. There is a lot of discussion in the Infocenter (yes I >found it!) regarding changing the time and it's effect on scheduled jobs and >other time-dependant operations. >> Time adjustment is not used as that would cause the minute >> after 2:00 AM to be "something" between 2:00AM and 3:00AM. >> This time value (for example purposes 2:01AM) does not exist >> (per your legislative authorities). >OK, I never thought of the time 'not existing' for legal reasons. But what >about the other direction in the fall? Does the time 1:30am legally occur >twice? 1:30 AM does indeed occur twice. Once for 1:30 AM EDT and once for 1:30 AM EST. Unfortunately most applications don't currently present the applicable time zone name (or abbreviation in my example) so 1:30AM is ambiguous when shifting to standard time. The names and abbreviation can be seen by looking at QN0500EST. >> It is because of these types of headaches that the system >> internally tracks time with UTC (rather than local time) >> starting with V5R3. UTC does not have the concept of DST. >> Time simply moves forward, and the system then converts the >> internal UTC times to the appropriate local times based on >> the time zone in effect. To avoid time shifts the use of a >> standard such as UTC is the way to go. Local times are just >> too easily changed by government decisions. >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? In V5R3 and V5R4 QHST continues to use local system time. I would not be surprised though to see this change in a future release. If at some point in the future the system allowed each job to run in it's own time zone and QHST normalized the messages to UTC then yes, one user may see the QHST entry in New Zealand time, another user the same entry in Eastern US time. >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.) I'm not familiar enough with the Advanced Job Scheduler to say for sure, but the i5/OS provided scheduler would run the job once -- for the first 1:30AM (assuming you're doing absolute time of day submissions). Bruce Vining -- 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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.