Is Your IBM i Ready for Daylight Saving Time?

This week's blog was written by Angela Newton from the IBM i Work Management team. Thanks, Angela!

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 11^th 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 Systems Navigator Director 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 Information Center.

 

 

 

Comments

[Russ Edwards]

So after reading your post I wondered: In RPGLE, how would I get the current UTC in timestamp format (to avoid some of the issues you mentioned at the beginning)? I check a few APIs and noticed that QWCCVTDT has had some optional parameters added since I last used it. It appears that calling it with appropriate values and then converting the 20-character output with %timestamp(Output:*ISO0) will do it. Or is there an even easier way?

[Angela Newton]

Russ, you are correct. The Convert Date and Time Format (QWCCVTDT) API can be used to convert from UTC to another time zone or vice versa and can be converted to one of several formats. It can also be used to get the current time of day and return it in any format. I'm not an RPG expert, but I believe there may a built-in function to get the current date-time also, but I think the RPG run-time uses this same API under the covers, so I guess it depends on what you are doing, as to which would be easier.