Daylight Savings Time

Written by Mark Mergaerts in Technology

 

For most humans, the switch to Daylight Saving Time just means an extra hour of sleep. But for software applications, the consequences are less appealing. Software often contains functions that are time-dependent. In many cases, the integrity and recoverability of data can depend on it. Due to the switch to Daylight Saving Time or DST, a phenomenon we call the ‘double hour’ occurs: the period from 02:00 to 03:00 occurs twice. This might upset the system technology and the chronology of the data it contains. But what can you do about it – and what are the pros and cons of each approach? Our expert Mark is happy to share his expertise and experiences.

Pexels negative space 34584 1

In order to avoid data or chronology issues, the basic recommendation for SAP is to stop the system, for a little over two hours, so that the system never registers the ‘double hour’. In this case, you stop the system at 01:55 and restart it at 03:05, with five minutes on either end acting as a safety margin. This results in a total downtime of two hours and ten minutes. Although Sunday mornings are generally a quiet period, a two-hour downtime may still present problems. If this is the case for your company, SAP offers two possible solutions.

  1. The one-hour downtime solution, which shortens the downtime to just over an hour. For this solution, it is important to know how your server O/S will deal with times within the double hour. Depending on how the operating system handles summer and winter times, it will make an assumption based on the time you switch the system back on. Some assumptions allow you to shut down the system for just over an hour, while others may cause the same ‘double hour’ problem as before if you didn't shut the system down for two full hours. To help you figure out how your server deals with times inside the hour, SAP has delivered a tool as an attachment to note 102088. This way, you can check how your server O/S deals with winter and summer times and set your downtime interval based on what the tool tells you.
  2. The no-downtime solution, which gets rid of downtime completely. With this solution, the time is artificially slowed down, a concept SAP calls ‘stretched time’. The clock slows down for two hours to match reality by the end of the countdown, and no ‘double hour’ occurs. This mechanism is controlled via a profile parameter (zdate/DSTswitch_contloctime) without having to restart the system. Bear in mind that although using this parameter will allow you to avoid downtime, there is a price to pay: during the double hour, the time reported by the SAP system will not be the real time.

Choosing which approach works best for your company or system depends on the server O/S and on the activity of the SAP system during the critical period: can you allow the clock to slow down? Or do you have to prevent stretched time and go for downtime? Will your server correct the time switch after one hour, or will it need two hours for full accuracy? Finding the perfect solution is all about knowing your system and your company’s needs.

Daylight Saving Time

Daylight Savings: For most humans this means an extra hour of sleep, but for software applications the consequences are less appealing. Read why the Daylight Savings time switch is a good deal trickier than the switch from winter to summer time.

Download the whitepaper
Daylight Saving Time

About the author

Mark Mergaerts

Mark Mergaerts has more than 25 years of experience in SAP Basis Consulting. He knows the ins and outs of databases and landscapes and is highly experienced in performance and tuning of ABAP systems and the adapting of customer code when migrating to a different database platform.

Read more articles by Mark Mergaerts