The speed-up and slow-down clock process is a hardware function. It works that way only on i5 hardware (model 520 570 etc.) If you have V5R3 on a 170 or 720 or even an 8xx box it will just SLAM it back) ========================================================== It doesn't matter what hardware or model is involved; the result is the same in all systems if the time zone support is used. Further, it works exactly as it should work -- immediately jumping forward or backward one hour. This is what happens to the time. The hour repeats in the fall and skips in the spring. It most definitely <b>should not</b> simply speed up or slow down. Because the time is set according to government standard, any attempt to sneak past it is essentially the creation of fraudulent timestamps. Audit requirements (with possible legal ramifications) demand that the times be set properly. If applications are not written to account for something that's happened every year for the past 40 years in most of the nation, the developers need to be replaced. Two specific methods of handling it are to suspend processing of transactions for one hour at 2:00 AM in the fall upon reaching the end of Daylight Saving Time or to record all times as UTC and only convert to/from local time in the presentation layer. Tom

The speed-up and slow-down clock process is a hardware function. It works that way only on i5 hardware (model 520 570 etc.) If you have V5R3 on a 170 or 720 or even an 8xx box it will just SLAM it back) ========================================================== It doesn't matter what hardware or model is involved; the result is the same in all systems if the time zone support is used. Further, it works exactly as it should work -- immediately jumping forward or backward one hour. This is what happens to the time. The hour repeats in the fall and skips in the spring. It most definitely <b>should not</b> simply speed up or slow down. Because the time is set according to government standard, any attempt to sneak past it is essentially the creation of fraudulent timestamps. Audit requirements (with possible legal ramifications) demand that the times be set properly. If applications are not written to account for something that's happened every year for the past 40 years in most of the nation, the developers need to be replaced. Two specific methods of handling it are to suspend processing of transactions for one hour at 2:00 AM in the fall upon reaching the end of Daylight Saving Time or to record all times as UTC and only convert to/from local time in the presentation layer. Tom