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.
- 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.
- 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.