I have just learned that there will be a leap second before January 1, 2017. A leap second is an extra second added to a day to keep UTC (Coordinated Universal Time) synchronized with "mean solar time". The leap second is added to December 31, 2016, after 23:59:59 UTC, and before 00:00:00 UTC on January 1 2017.
| December 31, 2016 | 23:59:59 UTC |
| 23:59:60 UTC | |
| January 1, 2017 | 00:00:00 UTC |
The question is how does this effect IBM i?
IBM made an announcement in July of this year describing its effect on IBM i.
The IBM i Operating System will not be affected by the Leap Second Adjustment. The IBM i Operating System will not automatically add the leap second at the end of December 31, 2016, at 23:59:60 UTC.
If your IBM i Operating System is configured to to utilize the NTP time protocol service via the network, the leap second will be adjusted by this service.
If your IBM i Operating System is not configured to utilize the NTP time protocol service via the network, you will need to make the leap second adjustment manually by changing the QTIME system value.
You can configure NTP on IBM i using the Change SNTP attributes, CHGNTPA, command. This should be performed by a system administrator, and I am not going to give details on how to do this except to provide a link to IBM's documentation for this command at the bottom of this post.
If you do not use NTP then you will need to adjust the time manually after January 1, 2017 00:00:00 UTC. The exact time depends upon which time zone your IBM i is in.
The last leap second was on June 30, 2015.
Simon, I have two systems that I administer that do not use NTP. Because of this, the clocks do drift as IBM does not use the power line to keep the clocks correct. What I have done is set up a TIMEADJ data area (3,0) that will adjust the clock at IPL by the number of seconds in the data area. After the adjustment is made, if it is a negative adjustment, the program does a DLYJOB command for the same number of seconds to reduce any possibility of overlapping times. On one system, running V4R5, this same program also can change the time from Daylight Saving Time to Standard Time and vice versa. (The V5R4 system handles this automatically.) The V4R5 system waits an hour in the fall when the time falls back. For this leap second, the clocks are more than a second off, so there is no point in making an addition adjustment.
ReplyDeleteDo the clocks drift by the same number of seconds over a period?
DeleteIf there is a pattern to the drift, I'm not seeing it. However, they do tend to run slow. Today, the V4R5 system is one minute, 33 seconds slow and the V5R4 system is 24 seconds slow. Generally, if they're no more than a minute slow, I don't worry about it. They IPL on Sunday so I guess I will have them adjust the time next Sunday.
DeleteNote that systems using NTP drift as well; it's just that the NTP corrects the drift on a periodic basis.
Later today, I'll get you some logs from a system that does use NTP. I'll see if I can figure out when it adjusted for the leap second.
Simon,
DeleteThe NTP logs are found with this command:
wrklnk '/qibm/userdata/os400/tcpip/ntp/*'
I have included logs from 12/31 and 1/1 which will show the adjustment in the IBM i server clock to adjust for the leap second. If you think about it, the server clock has to be set back by a second to get back in sync. Once the NTP server itself started picked up the leap second (which took it an hour), the adjustment to the IBM i server was done over three hours. It was done in four increments: .420 seconds, .403 seconds, .161 seconds and .094 seconds. These add up to more than a full second as the IBM i server clock drifts 27 msec per hour (Or not as accurate as the Timex on your wrist. You would think they could do better than that.)
Here is an excerpt from the logs with the actual name of the NTP server redacted; times are in Eastern Standard Time (U.S.):
Using time server …
12/31/16 1:09:36.442 PM Time remaining for adjustment is 0.000 seconds.
12/31/16 1:09:36.442 PM NTP server UTC time is 12/31/16 18:09:36.459.
12/31/16 1:09:36.442 PM Client clock UTC time is 12/31/16 18:09:36.439.
12/31/16 1:09:36.442 PM Client clock adjusted = 1 (0 = not adjusted, 1 = adjusted)
Using time server …
12/31/16 8:09:36.863 PM Time remaining for adjustment is 0.000 seconds.
12/31/16 8:09:36.863 PM NTP server UTC time is 01/01/17 1:09:36.443.
12/31/16 8:09:36.863 PM Client clock UTC time is 01/01/17 1:09:36.863.
12/31/16 8:09:36.863 PM Client clock adjusted = 1 (0 = not adjusted, 1 = adjusted)
Using time server …
12/31/16 9:09:36.520 PM Time remaining for adjustment is 0.000 seconds.
12/31/16 9:09:36.520 PM NTP server UTC time is 01/01/17 2:09:36.117.
12/31/16 9:09:36.520 PM Client clock UTC time is 01/01/17 2:09:36.520.
12/31/16 9:09:36.520 PM Client clock adjusted = 1 (0 = not adjusted, 1 = adjusted)
Using time server …
12/31/16 10:09:36.603 PM Time remaining for adjustment is 0.000 seconds.
12/31/16 10:09:36.603 PM NTP server UTC time is 01/01/17 3:09:36.442.
12/31/16 10:09:36.603 PM Client clock UTC time is 01/01/17 3:09:36.603.
12/31/16 10:09:36.603 PM Client clock adjusted = 1 (0 = not adjusted, 1 = adjusted)
Using time server …
12/31/16 11:09:36.515 PM Time remaining for adjustment is 0.000 seconds.
12/31/16 11:09:36.515 PM NTP server UTC time is 01/01/17 4:09:36.420.
12/31/16 11:09:36.515 PM Client clock UTC time is 01/01/17 4:09:36.514.
12/31/16 11:09:36.515 PM Client clock adjusted = 1 (0 = not adjusted, 1 = adjusted)
Using time server...
01/01/17 1:09:36.553 AM Time remaining for adjustment is 0.000 seconds.
01/01/17 1:09:36.553 AM NTP server UTC time is 01/01/17 6:09:36.597.
01/01/17 1:09:36.553 AM Client clock UTC time is 01/01/17 6:09:36.543.
01/01/17 1:09:36.553 AM Client clock adjusted = 1 (0 = not adjusted, 1 = adjusted)