ABAP log

February 19, 2007

Handling date and time on SAP systems running across multiple time zones.

Filed under: ABAP, SAP — abaplog @ 8:18 pm

The easiest way to prevent any time zone problems is to run everything with UTC (formerly GMT – Greenwich Mean Time). But while it’s a good idea for servers, end users will most likely complain about being confused (my family doesn’t – my home systems are on UTC to prevent the hassles with summer/winter time). And if you implement SAP using local time on the server, while your users are in different time zones, things can get slightly complicated. Just try searching in OSS with search term “sy-timlo”.

The main problem is that some fields in SAP are stored as server local time (and date), while others use user’s local time. In general, as SAP explains in many OSS notes, any date/time that is written by the system is server local time, and any date/time that can be manually entered by users is in respective user’s time zone. To help us even more, the time zone used is not stored in documents, but only in user profile, so to be really sure which time is meant, one has to find the user who did the data entry or update, and then find the time zone and do conversion if necessary. SAP gives a good example in OSS note 636992. There, a user sitting in Japan creates a notification about, for example, machine breakdown, entering local time. Several hours later, a colleague in Germany looks at the notification and thinks that the machine has been down only a few moments, while it’s actually several hours!

Things are enough confusing if you are analysing some problem by looking at the data. And if you are creating documents (material movements, accounting postings or production order confirmations) from ABAP programs with, for example, BAPI functions, you have to be especially careful because the system will run checks on date and time fields, with different logic. In general, the posting date (BUDAT or, as in BAPIs, POSTG_DATE) and several date/time fields like EXEC_START_DATE, EXEC_START_TIME, EXEC_FIN_DATE, EXEC_FIN_TIME, EX_CREATED_DATE/TIME in confirmations in the BAPI function BAPI_PRODORDCONF_CREATE_TT are your local date and time. While creating order confirmations, the system will check the date/time against the user local date and time and will prevent creating confirmations in the future. In contrast to PP, the BAPI to create a goods movement – BAPI_GOODSMVT_CREATE – assumes that posting date is a local date, but doesn’t complain if it’s in the future. The potential problems can be hard to find and detect: if you have small time differences, the posting date can differ only during one-two hours per date – only then you will get an error when posting an order confirmation. For all those fields mentioned above you should normally use the system fields SY-DATLO and SY-TIMLO if they have to be populated with current date and time. If the data is provided by an external system, then either the system has to care about the correct time, or your ABAP program has to do time zone conversion.

In certain situations you can assume that if a document is being created for some plant, then the current server time can be converted into local time of the plant, if you know the time zones of both. The server’s time zone, or more exactly, its difference with UTC, can be found in the system variable SY-TZONE. To find the time zone of a plant, you can use the logic that can be found in the function CO_R0_SET_LOCAL_DATE_AND_TIME.



  1. Hello, I was trying to find some information as to what we would need to
    consider moving the system time to Universal Common Time. Then I found your post. We are
    consolidating instances and are looking to eleminate the need for an
    outage for time changes.
    Due the opposite time shifts between the Northern and Southern
    Hemispheres with DST, the current server time (GMT+DST) would require
    the servers to be brought down twice annually for time adjustments.
    Moving to Universal Common Time (which is GMT w/o DST) would avoid
    taking the SAP Servers down for this time adjustment process is the thinking. I am concerned about the end-user impact which you highlighted in your post as well. Are there any other pitfalls challenges that one would need to think of. As of Web AS 640 there is the DST safe functionality – wouldn’t this resolve many of the issues?

    Comment by Stefan — July 22, 2007 @ 11:57 am

  2. Well, even if you use their wonderful feature, which is not new in computing world (look for “NTP” and related software), you still have your users. Which means, PCs of those users who work during time changes in their time zone have to be slowed down, sped up too, if they don’t work in UTC. How can you administer that easily? No idea if you have night shifts workers (Saturday to Sunday). Luckily it’s only for manufacturing – and those guys usually don’t care that much. Sales folks, for whom local time is important, do not work on weekends. I have discussed just a tip of an iceberg. I worked once on a system that was on UTC, but I can’t say unfortunately how the user PCs were set up. All that has to be carefully planned for each company. Probably, UTC on the server so that you save on downtime but users that are going to get through the time change banned for that hour? It’s anyways much better that the full shutdown.

    Comment by abaplog — July 23, 2007 @ 7:58 pm

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: