Daylight Saving Time Starts on 31 March 2019

April 1, 2019 Posted by: Mark Mergaerts
clock blog daylight savings-1

EXPERTUM TECH ALERT - In 2019 the change to Daylight Saving Time (DST) in Western and Central Europe takes place on the 31st of March at 02:00 in the morning (please see the table at the end of this blog for other continents and regions). 

From an IT perspective the March time change is the “easy” one: clocks go forward one hour, so no “double time” occurs. Nevertheless we thought it would be useful to remind you of some basic rules and recommendations regarding time changes and your SAP systems.

The key SAP note on changes to and from DST is note 7417. The current version of this note dates from November 2011, so there are no major changes compared with last year; however, do check the section Platform-specific and component-specific warnings later in this Newsflash. The note mostly deals with the much trickier switch from DST back to standard time (“winter time”, also covered by a separate Newsflash to be sent out in the autumn) but it does raise a few points that you must keep in mind even when the clock goes forward.

Background jobs

All time-dependent activities that are scheduled to run during the “lost” hour (between 02:00 and 03:00 on the Sunday morning) will be affected. This goes first and foremost for background jobs with fixed start times. The normal behaviour is that background jobs will become active when their start time is reached. For example if a job is scheduled to start at 02:15 and the clock jumps from 02:00 to 03:00, the job will immediately become eligible for running. In most cases this is not problematic, but keep the following situations in mind:

  1. When scheduling a job it is possible to set not just the start time but also a “do not run after” time. This could lead to the job being skipped completely. Example: a job is scheduled to run at 02:15 but not to start after 02:45. If the clock jumps from 2 o’clock to 3 o’clock the permissible end time has passed and the job will not run.
  2. A job might also start prematurely. Suppose that a job is scheduled to run hourly, starting at 15 minutes past the hour. On the night of the time change it will run at 00:15 and 01:15, but the next run will happen not at 02:15 (which never occurs) but at 03:00. This means that only 45 minutes have elapsed between this run and the previous one, and only 15 minutes will pass before the job runs again at 03:15. Again, such behaviour might be entirely harmless, but it is something to be checked in advance.
  3. BI extractors for New General Ledger (NewGL) may run into trouble; see Platform-specific and component-specific warnings

Time calculations

The date and time data types in ABAP make it very easy to calculate the distance between two times. The natural tendency is to use the system-defined values SY-DATUM (current date) and SY-UZEIT (current time) for this.

However these values are time zone dependent and thus cause calculation errors whenever they cross a daylight savings time boundary. The prescribed solution is to use the TIMESTAMP form, which uses Universal Time (UTC) and therefore never jumps forward or backward. However, this rule is not always followed. If an application critically depends on the calculation of time differences (time registration is an example that springs to mind), then you should be aware of this and take necessary precautions for the night of the time change.

Small time differences between database and application server

If you have a distributed system (a SAP system with at least one application instance running on another server than the database server), then you must pay attention to the time settings on the different servers. A database server and all application servers running instances that access this database must always be on the same time zone. In addition  - and this is important for the time change – clock times on the servers should be synchronized so that all servers show the same time. The reason is that while a transaction is executing the SAP kernel checks for time differences between the application and database server. If an important difference is found then the kernel assumes that timestamps used for locking may be compromised, which threatens data integrity. To protect against this the active transaction is aborted and an ABAP dump with keyword ZDATE_LARGE_TIME_DIFF is produced. In such circumstances it is even possible that the SAP application server will shut itself down (see note 1913285).

If a small time difference exists between the servers then your system is at risk of running into this problem. Let’s consider an example: in a distributed SAP system the application server is 15 seconds behind the database server. When the system time on the DB server becomes 02:00:00, the clock on that server jumps to 03:00:00. However on the application server the system time at that same moment is still 01:59:45. At this point a time difference of more than one hour exists between the two servers; it will take 15 seconds before the time jump is made on the application server and the gap is again closed. This means that there is a 15-second window of vulnerability during which transactions and jobs could abort with ZDATE_LARGE_TIME_DIFF.

To summarize

  1. Identify all background jobs due to run on Sunday, 31 March between 2 AM and 3 AM and ensure that the 1-hour forward time change does not adversely affect these jobs. If in doubt postpone the job until after 3 AM.
  2. Find out with the application owners/key users whether there are applications that are dependent on exact timing or time difference information and determine how these applications should be handled during the night of the switch to DST.
  3. Ensure that clock times are synchronized to the second between the database server and the application servers.
  4. Check the platform- and product specific warnings below to see whether any of these apply to your SAP environment

Platform-specific and component-specific warnings

    • Possible terminations caused by time difference between application and database server; see note 1932132
    • Check HANA DB for DST switch: SAP note 2080216
  • Software Update Manager (SUM): in note 2557518 SAP recommends stopping the SUM at a time before the change to Daylight Saving Time, i.e. sometime before 2 AM on Sunday morning, and only resuming it after the change has occurred.
  • IBM AIX 3, 6.1 and 7.1: various known issues regarding time synchronization and ZDATE_LARGE_TIME_DIFF are known. Please consult notes 1155698 – 1226144 – 1692629 for details.
  • IBM iSeries: please see SAP note 391658.
  • NewGL delta extractor to BI: various problems if extracted runs at the time of the DST change; see notes 1454474 and 1581238

Key SAP Notes




Conversion between standard time and daylight saving time


iSeries: Daylight saving time/standard time change






0FI_GL_14: Problems with change to daylight saving time




SAPI supports the daylight saving time change for 0FI_GL_14


System time may not change properly at DST start/end (AIX)


Termination ZDATE_LARGE_TIME_DIFF and server shutdown


SAP HANA : Large time difference between application server and HANA database


Check HANA database for DST switch


Running the SUM (Software Update Manager) during DST switch


Other information sources

SAP Community Network (SCN) Wiki: "Timezone changes best practices" by Naveen Kumar Vasan,

Time difference with other time zones

EU member states

All member states of the European Union (still including the United Kingdom) change to DST at the same time, which means that the time difference between countries in different time zones remains the same. For example, in the UK and Ireland, the change happens at 1 AM local time. In countries on Central European Time, like Belgium or The Netherlands, it happens at 2 AM, and in countries on Eastern European Time (e.g. the Baltic countries, Bulgaria and Romania) the switch is made at 3 AM local time.

European non-EU states

European countries that are not members of the EU, including the non-EU Balkan nations, Norway, Switzerland and Ukraine follow the same rule as the EU.

Russia and Turkey do not observe DST.

Other continents

The site is an excellent source for DST information worldwide.


  • In the United States and Canada the change to DST already took place on Sunday 10 March.
  • China, Japan, South Korea and South Africa do not change the clocks.
  • Morocco used DST until October 2018 but has since abolished it. The clocks no longer change. Other countries in North Africa do not change DST either.
  • Many countries in the southern hemisphere, including Australia, New Zealand and Chile, change to winter time (clocks go back one hour) on 7 April.

Any questions on this topic?

Contact us


Mark Mergaerts

Development Manager within Expertum Belgium