On the outset, this seems like something that should have been covered plenty of times before. However, you’d be surprised at the complexity of this simple operation.
We’re going to go through the options for how this can be achieved and show a scenario based on a company operating in the CET (Central European Time) timezone.
What’s the deal with the time changing?
I’m sure you will already know this, but just to recap for the sake of completeness:
- In Europe (America is different) on the last Sunday of March, the northern hemisphere begins summer time. In our scenario, CET is swapped for CEST (Central European Summer Time).
CEST = CET + 1 hour.
- In Europe (America is different) on the last Sunday of October, the process reverses. We swap CEST for CET. So we go back in time one whole hour.
- On the last Sunday of October, at 02:59:59, the next second changes the time to become 02:00:00 again (it goes back one hour).
This is known as the double hour.
- The period from 02:00:00 to 02:59:59 is known as the double hour period because those times are seen twice in the same day.
- The double hour period causes some SAP applications problems because they are not able to adequately record the double hour period within their transactional processing capability. Simple example, a bank transaction record is recorded as happening at 2:15am, but which 2:15am during the double hour period?
So that’s the problem.
The common solution is stop the SAP system during the double hour period.
I’ve seen and heard of a raft of different requirements for solving this.
Some companies stop the system starting at 1:30am, some don’t stop it until 2:30am (the first 2:30am). Some stop the whole SAP landscape including the database and some stop just the SAP application layer.
What does SAP and the SAP notes say on this?
There are a few resources to help you decide what you need to do:
- SAP Note 7417 “Conversion between standard time and daylight saving time”
- SAP Note 102088 “Reducing downtime when chaning from summer to winter time”
Based on the notes, we can see there are 3 options available to us:
- SAP downtime for just over 2 hours.
- SAP extended time.
- SAP minimal downtime for just over 1 hour.
Let’s highlight the options.
SAP downtime for just over 2 hours.
This is the standard approach and the approach recommended in the SAP notes, because it is the safest, catch-all approach.
You simply need to stop the SAP application layer before 02:00:00 and keep the system shutdown during the double hour period. Starting the SAP system back up again after 03:00:00.
During this approach, the databases can remain online, so why not do some DB maintenance…
SAP extended time.
In SAP Kernel 6.40 back in 2004 sometime, SAP introduced a new parameter and a capability within the Kernel which would automatically adjust the SAP system time, compared to normal clock time.
The new parameter is automatically activated (“ON”) by default.
On the day of the time change, at 02:00:00, the SAP Kernel starts to slow down the SAP system time, so that by 02:59:59 (clock time) the SAP system time is 30 mins slower (SAP time would be 02:30:00). Then after the clock time resets back 1 hour to 02:00:00, the SAP Kernel starts to slowly speed up the SAP system time again, so that at 03:00:00, both the clock time and the SAP system are synchronised again.
This method means that the SAP application never sees the double hour.
Sounds great. No need to stop the SAP system.
There are potential issues with ABAP code that compares the O/S time with the SAP system time (SY-UZEIT/SY-DATUM).
SAP note 7417 states that this “SAP extended time” option is only supported by SAP applications that are listed in the “referenced by” section of SAP note 7417.
There are no SAP applications listed in the “referenced by” section of SAP note 7417!!
There is SAP note 1454474 which specifically mentions issues with the double hour during a BW extract in an ECC system. In this note, the solution is to stop the SAP system. So it would appear that ECC is definately not capable of using this “SAP extended time” option.
SAP minimal downtime for just over 1 hour.
We talked about stopping the SAP system for just over 2 hours. This option is a modification on that option, but it needs some timezone alignment in the technology stack of the SAP system.
If your server timezone is CET, and the O/S locale timezone for your SAP application owner (e.g. <sid>adm) is also CET and your SAP system timezone is CET, then you are aligned.
If you have alignment of the timezone as mentioned above, then it means that all the technical layers will switch time at the same time.
This is difficult to explain, but imagine the O/S timezone was BST (British Summer Time) and the SAP system timezone was CEST, the CEST timezone is 1 hours ahead of BST. This means that first CEST would switch to CET then one hour later, BST switches to GMT (Greenwich mean time). The problem here is that without alignment, the SAP system would potentially have issues with ABAP code that compares the O/S time with the SAP system time (SY-UZEIT/SY-DATUM).
With alignment, you can potentially reduce the downtime to just over 1 hour because you know for certain that your SAP system experiences only 1 double hour period.
Before 02:00:00, you must disable the dynamic “SAP extended time” parameter “zdate/DSTswitch_contloctime”, so that the SAP system does not start to slow it’s system time.
Then you can stop the SAP application layer before 02:59:59 and start it up safely after 03:00:00 (a 1 hour downtime).
During this approach, the databases can remain online, so why not do some DB maintenance…
SUMMARY
For SAP Business Suite (and S/4), there are only really two options: ~ 2 hours of downtime or ~1 hours of downtime.
To use the 1 hour downtime option, there is a dependency on your timezone alignment of the technical layers.
To use the 2 hour downtime option, you must stop the SAP system before 02:00:00 or the SAP system will automatically have started to slow it’s system time which might cause you issues if you need to rely on timestamps outside the SAP system correlating with timestamps inside the SAP system.
For custom applications ontop of SAP Netweaver AS, if your ABAP code does not perform comparison of SY-UZEIT vs SY-DATUM, then you can probably use the “SAP extended time” option, but you should test it.
