Daylight Saving Time is just around the corner and if you’re like me, you aren’t looking forward to “losing” an hour and getting up earlier. I also dislike having to change all my clocks, although I have noticed this task has gotten easier recently, with several devices such as cell phones and DVRs making the transition all on their own. The IBM i falls into that category of making the DST transition automatically, but it hasn’t always been that easy.
Time zone objects were first introduced in V5R3. Prior to that, the system time had to be manually adjusted twice a year if you lived in an area that observes daylight saving time. The process could be somewhat automated by scheduling a job to change the QTIME system value, but it still required an actual time change, potentially causing problems such as incorrect calculations when time is moved forward or backward and duplicate timestamps when time is moved backward. This shift in time can be problematic for applications that assume timestamp values are always increasing or rely on unique timestamps – for example, when a timestamp is used as part of a key in an index or table.
The system clock internally tracks time based on Coordinated Universal Time (UTC) and then maps the UTC values to local system time. This mapping from UTC to local time is done with the help of time zone objects. A time zone object defines the UTC offset (or difference in time, positive or negative, from UTC in hours and minutes), the daylight saving time observance (if any) including the start and end specifications, for instance, the second Sunday in March at 2:00AM, along with the number of minutes to shift by, and the descriptive name and abbreviations, i.e., Central Standard Time (CST) and Central Daylight Time (CST).
Now that the system uses time zone objects, the internal system clock itself does not change for DST. When transitioning to or from DST, the system’s offset from UTC time (QUTCOFFSET system value) is updated, thereby changing the system local time (QTIME system value). QTIME is not the same as the system clock, but rather is a reflection of the system clock (which is maintained in UTC) with an offset (from UTC time) applied. In other words, a system here in the Midwest with QTIMZON set to QN0600CST2, will have QUTCOFFSET currently set to -6:00 hours. On March 11th at 2:00AM, QUTCOFFSET will change to -5:00 hours. As a result, when you display QTIME at 2 o’clock AM, the local system time will then show 3:00AM.
This means that you set the date and time and time zone once for your partition and after that, no time changes are necessary. If you change to a different time zone, or there is a change in rules for Daylight Saving Time (for example when the US extended Daylight Saving Time in 2006) you simply make a change to use the new time zone. There are several commands and APIs to work with time zones on the IBM i. A good place to start is the Time Management task in IBM Navigator for i or the Work with Time Zone Descriptions (WRKTIMZON) command. This lists all the system supplied time zone objects, and has options to display, change, delete and update the time zone. The following screen capture shows a portion of the available time zones.
For more information on these and other time zone interfaces, see the Time Management topic in the IBM i Knowledge Center.
This week’s blog was written by Angela Newton from the IBM i Work Management team. Thanks, Angela!
This blog post was originally published on IBMSystemsMag.com and is reproduced here by permission of IBM Systems Media.