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

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.