Logos Alerts will be sent out every year before the change to Daylight Saving Time (DST) and the change back to standard (winter) time. The current Logos Alert contains the same basic technical information as Alert #25 of October 2015, but has been updated with the most recent data.
On Sunday, 30 October 2016 most of Europe changes from Daylight Saving Time (“summer time”) back to “standard” or “winter” time. Here in the Central European Timezone (CET) the change happens at 3 o’clock in the morning. At that moment time goes back one hour and 03:00 becomes 02:00. For most humans this means an extra hour of sleep or partying, but for software applications the consequences are less appealing:
- Software often contains numerous functions that are time-dependent; the integrity and recoverability of data may even depend on it. These functions do not normally react kindly to a sudden backward time shift.
- Because the clock goes back, there is a “double hour”: in our case the period from 02:00 to 03:00 occurs twice, once in summer time and again in winter time. Again, software is likely to have problems with this: scheduled functions may run twice and chronology may be upset (for example a document created at 02:15 winter time would be regarded as older than one created at 02:40 summer time, although in reality it is newer).
This makes the upcoming time switch a good deal trickier than the “easy” switch from winter to summer time, which is described in the springtime version of this Alert (see Logos Alert 21); hence the Alert now before you is a good deal longer.
The key SAP note on changes to and from DST is note 7417. The basic recommendation, and the one followed at many SAP sites, is to stop the SAP system (including the database) for a little over two hours. This downtime must be planned in such a way that the system never sees the “double” hour, i.e. system time between 02:00 and 03:00. The example cited in the note is to stop at 01:55 a:nd to restart at 03:05, the five minutes on either end acting as a safety margin. This results in a total downtime of 2 hours and 10 minutes.
Sunday mornings may generally be a quiet period, but it is possible that a 2-hour downtime presents problems. If so, another solution involving a shorter downtime – or even no downtime at all – is needed. For this situation SAP has two answers:
- The first solution shortens the downtime to just over one hour
- The second solution gets rid of downtime completely – but at the cost of some accuracy
THE ONE-HOUR DOWNTIME SOLUTION
What if you stopped the system say at 01:55 summer time, but restarted it already at 02:05 winter time? The downtime would only be 1 hour and 10 minutes instead of 2 hours. Chronology would not be disturbed because the clock would not brutally go backward and no time would occur twice. This looks an easy way to almost halve the downtime at no cost.
Unfortunately there is a snag and that is the way the underlying operating system deals with system times. All operating systems use a “timezone database”, which specifies how each timezone and country/region handles the switch between summer and winter times. For example the timezone entry for CET indicates that the switch to winter time happens on the last Sunday in October at 03:00 and that the clock shift is -1 hour. This implies that the O/S also knows when the “double hour” occurs.
Now what happens for example during the night of the time switch if the system time on the server is 02:01? Is that one minute after 2 o’clock summer time or one minute after 2 o’clock winter time? The answer is: the O/S will make an assumption and that assumption is system-dependent. Back to our example: if you restart at 02:05 winter time, the system will run for 55 minutes in a period the O/S considers as double time and where consequently it will apply its double hour rule. Let’s suppose that the rule for your O/S says that times from 02:00:00 until 02:59:59 is considered part of summer time. You know – and your watch tells you – that winter time has begun but the server thinks it is still in summer time. This may lead to incorrect timestamps and thus to chronology errors.
To avoid this problem and still benefit from a 1-hour downtime you must therefore know up-front how your server O/S will deal with times inside the double hour. To help you with this, SAP delivers a tool as an attachment to note 102088. This tool is a C program (not an ABAP program) called “endofdst”. The attachment contains the C source and a compiled EXE for Windows; for UNIX you will have to compile the source yourself.
When you run endofdst, it asks you to enter any date and time that you know lies inside summer time. It then displays the double-hour rule of the server, which tells you the latest time to stop the server. Below is an example from Windows; notice that I entered just a random date and time in early October – as long as it falls inside summer time any date is OK.
The output of the program tells me that on this server summer time ends at 01:59:59. In other words, the O/S will treat times between 02:00 and 03:00 as winter time. To come back to the example: in the case of this server stopping at 01:55 and restarting at 02:05 would be safe. Times between 02:05 and 03:00 would be winter time, both in the real world and for the operating system. However, stopping at 02:55 and starting at 03:05 would not be safe here, because the period from 02:00 to 02:55 lies in reality still in summer time but the server thinks it is already winter time. If your server tells you that its summertime ends at 02:59:59 then the reasoning is the other way round: the early stop is unsafe, the late stop is OK.
If your SAP system is distributed over multiple servers you must make sure that they all handle the switch in the same manner, i.e. the time switch happens on the same date and hour and the O/S assumption about the double hour is the same. To check whether the switch date/hour is the same everywhere SAP supplies another program, “sapttz” an attachment to note 398374. This is again a C program; the note attachment is a ZIP file containing a compiled program for Windows (called sapttz_win32.exe) and for other platforms the source code, which you will have to compile.
Output on Windows:
(The complete output shows the changeover dates for the next three years but I have truncated the output to show only the first part)
No surprise here of course: sapttz tells us something we knew already, but if your servers have different timezone settings then you might see different results.
If both endofdst and sapttz give identical results on all the servers of the SAP system, only then you may use the shortened downtime solution, choosing a proper time interval based on what endofdst tells you.
THE NO-DOWNTIME SOLUTION
The way to have no downtime at all is to pretend the clock never moves backward. Instead of a brutal jump from 3 o’clock back to 2 o’clock, the time (as seen by SAP applications) is artificially slowed down; SAP documentation refers to this as “stretched time”. At 02:00 (summer time) the clock slows down by half and it stays like this until two hours later at 02:00 (winter time). No “double” time occurs inside SAP and the way the O/S handles the double hours plays no role because the SAP kernel intercepts this information and takes control of the time inside SAP.
This mechanism is controlled via the profile parameter zdate/DSTswitch_contloctime. If set to “on” the slow-down of the clock in SAP happens as described above. If “off” no slow-done happens and the time coming from the server is used (which means there is a backward jump and a double hour, both of which you must protect against by stopping the system).
*** WARNING *** The default setting is on, so unless you explicitly change the parameter to “off”, the slow-down will take place! *** WARNING ***
The parameter is available in all SAP kernels of version 7.10 and higher. For older kernels (which hopefully you are no longer using because they are out of support), the minimum version is 6.40 patch 231 and 7.00 patch 139.
So what should you do with this parameter? Leaving it to “on” lets you avoid downtime completely but there is a price to pay: during the double hour the time reported by SAP will not be the real time. The slowing rate is uniform so at 03:00 summer time, one hour into the critical period, the SAP time is 02:30 or 30 minutes behind. At that moment the real clocks go back one hour, so the SAP time is 30 minutes in advance. The advance then gradually decreases again until 03:00 when real time and SAP time are again the same (see figure below):
Having this deviation of up to 30 minutes might not be acceptable: what for example if during this time SAP interacts with external interfaces via RFC, external files, database links, … ? A SAP paper about daylight saving time (see the list of information sources at the end of this Logos Alert) gives another real-life example, namely patient admissions to a hospital. Registering an admission time that can be up to 30 minutes wrong could be fatal in the literal sense of the word. Therefore you must decide, based on the activity of the SAP system during the critical period, whether you can allow the clock to slow down or whether you must prevent the “stretched time” behaviour and go for downtime. Note that zdate/DSTswitch_contloctime is a dynamically switchable parameter, so you can change it online (via transaction RZ11) without the need to restart the system; note, however, that if the system has multiple application instances you must of course change the parameter everywhere.
INSTALLING UP TO DATE TIMEZONE DATA
Worldwide information about time zones and switches between DST and standard time is maintained as customizing data in the SAP system. Because this information changes from year to year it is necessary to keep this customizing up to date. SAP distributes updates to the timezone information as an attachment (ZIP file) to note 198411. You can upload the data into the system by running the ABAP program TZCUSTIM.
There are three ways to handle the backward time shift to winter time:
- Stopping the system for (a little over) two hours, which avoids both the backward shift and the double hour problem
- Stopping the system for (a little over) one hour. This always avoids the backward shift. It also avoids the double hour on condition that you determine the safe interval for the stop. This is done by running the “endofdst” period supplied with note 102088 and the “sapttz” program of note 398374
- Not stopping the system at all and allowing the SAP system to slow down its internal clock during the double hour. This slow-down is the default method but might be problematic in certain situations. You must evaluate whether the approach is usable in your case; if not, you must explicitly alter the setting in the system and use one of the downtime methods instead.
Please consult SAP note 391658
Time synchronization on Windows
If your SAP landscape is based on Windows, or contains at least one Windows server, then there are known issue with the time synchronization problems between application servers. Please check SAP note 2046718 for a detailed explanation and for instructions on how to check that the synchronization is working correctly. While this is not directly related to the topic of daylight saving time, any problem in this area is of course more likely to show up when the system time is being manipulated, so please ensure that everything is error free.
- Naveen Kumar Vasan: “Timezone changes best practices” – SAP Community Network (SCN) Wiki
- Adam Csaba Goetz: “Importing up-to-date timezone data using TZCUSTIM” – SAP Community Network (SCN) Wiki
- (Specifically for ABAP developers) Zhi Lue: “Daylight Saving Time Options in SAP System” –
SAP Community Network (SCN) White Paper