Time Zones (CA-GTF-TIM)


Processes which cover more than one time zone primarily affect logistic functions such as availability checks, production planning, delivery scheduling, statistics and service provision, but they also affect financial accounting in areas such as treasury, inter-company transactions, and so on.

This function enables you to use dates and times that are comparable and exchangeable in applications that are implemented worldwide. For time-related applications, the SAP system can use local dates and times for proposed dates and validations (for example, to ensure that a requested delivery date is not in the past).

Global Application

Generally, users think and act in terms of their local time, and they also expect to use their local time in business transactions. When the SAP System is used for global transactions that span time zones, business partners and systems will have different local times. These differences in local times can lead to problems such as late postings and missed background processing.

For example, a company with its headquarters and database server in New York requires that all billing documents be posted by 5:00 p.m. Users in the company's Los Angeles office might expect that to mean 5:00 p.m. in Los Angeles, which is 3 hours behind New York time. Thus any users in Los Angeles posting billing documents after 2:00 p.m. local time would be posting their documents too late.

Local times can be compared and exchanged as long as they share the same time zone. However, for business processes spanning time zones, inaccuracies of up to 24 hours could occur. By normalizing date and time internally, this function eliminates problems that can arise from users working in different local time zones. For some transactions, the system normalizes dates and times by storing a time zone and a time stamp. Currently, this only takes place in a few functions, for example, in the delivery schedule and in the print spooler.


The Time Zone function is fully integrated into the SAP system kernel. This integration allows for faster conversions between system- and local dates and times.

The terms "system date" and "system time" refer to the database server's date and time. Since application servers are synchronized with the database server, these terms also correspond to the application server's date and time.


For this function to work properly you need to

·        Maintain customizing data for time zones

·        Define default time zone assignments for both the system and for users

You can override the default time zone assignments in the user profile.


Internal and External Representations of Time

To compare the local times of users in different time zones, the SAP system represents times differently externally and internally. The external representation of the time corresponds to a context-dependent local time. For example, in Germany, the time is represented in Central European Time (CET) and in New York in Eastern Standard Time (EST).

In some instances, the SAP system normalizes the internal system time to Universal Coordinated Time (UTC) which serves as a reference time. UTC corresponds to Greenwich Mean Time (GMT). By converting all local, relative times to absolute times based on UTC, the system can compare times and use them in calculations.

Times Stored with Dates

Considering dates alone is not sufficient to ensure exact time calculations. For time-critical processes, dates with times replace dates without times. A date standing alone, could easily result in a one day inaccuracy (for example, depending on the time of day, 3 February in Japan may still be 2 February in New York). For a date without a time, an inaccuracy related to time zones can be as long as 48 hours in an extreme case.

For time calculations, an accurate duration (for example, hours and minutes instead of days) must be used. Otherwise, chain calculations such as the following could be inaccurate by several days:

Times and Their References to Locations of Objects

All local times are relative to a particular location, and this location has a relationship to an object. This relationship is not explicit and the SAP system can derive it only from system data such as in the Customizing tables (for example, Table T001W for plants), master data, such as the data for ship-to parties, and document data that overrides Customizing and master data (such as a one-time address).

Examples of typical objects and their relationships to locations include

Company code

A posting date is relative to the location of the company code.


A goods issue or goods receipt date is relative to the location of the plant.