It is November. Autumn leaves are brown. The Temperature in Walldorf, Baden, Germany is around 0º C (32 F). That’s when water freezes. Time to dream of Summertime. Let’s have a look at Summertime (also known as Daylight Saving Time) and all that stuff.
System Fields for Date and Time
For general purposes, ABAP contains a set of system fields for date and time:
System field
|
Content
|
sy-datlo
|
Date in the current user's time zone.
|
sy -datum
|
Local date of the SAP system.
|
sy-dayst
|
Indicator for summer time. During summer time, "X", otherwise " ".
|
sy-fdayw
|
Factory calendar weekday. "1" for Monday , ..., "5" for Friday.
|
sy-timlo
|
Time in the current user's time zone.
|
sy-tzone
|
Time difference from the UTC reference time in seconds, ignoring summer time.
|
sy-uzeit
|
Local time of the SAP system.
|
sy-zonlo
|
User's time zone.
|
The values of all system fields in this table are implicitly set when the program is started, every time a screen layout of a screen is sent, and when the internal mode is set. The GET TIME command explicitly updates the system fields, except for sy-dayst, sy-fdayw and sy-tzone.
With the exception of sy-datlo and sy-timlo, all system fields refer to the local date and time of the current SAP system. The ABAP runtime environment clock is synchronized with the database server clock at regular intervals in order to calculate the local time of the SAP system. During the synchronization process, the ABAP runtime environment clock is set to the database server clock. Because this happens on all application servers in an SAP system, the ABAP runtime environment clock is synchronous with the clocks on all other application servers and with the database system clock, and thus shows the local time of the entire SAP system. The time zone on which the local time of an SAP system is based is the only entry in the database table TTZCU.
The content of sy-zonlo is taken from the user master record of the current user. The values of sy-datlo and sy-timlo are calculated from sy -datum and sy-uzeit and from the time zone of the SAP system for the time zone in sy-zonlo. If the user master record does not contain a time zone, or if it contains an invalid or an inactive time zone, sy-datlo and sy-timlo are set to the values of sy-datum and sy-uzeit. All valid time zones are defined in table TTZZ.
Note: Isn’t the naming of sy-datum and sy-uzeit really geek?
Time Stamps
The above system fields for date and time are not sufficient for many requirements of determining unique points in time: They represent local times and the values are measured in seconds. For more exact date and time determination, you use time stamps.
A time stamp represents date and time in the form YYYYMMDDHHMMSS. YYYY is the year, MM the month, DD the day, HH the hour, MM the minutes and SS the seconds. There is a short form and a long form. In the long form, the format specified above additionally contains 7 decimal places for fractions of seconds, which allow for an accuracy of up to 100 ns. The maximum time resolution depends on the operating system of the application server and can be less.
A valid time stamp must contain values, whose date and time specifications before the decimal separator correspond to valid values for the data types d and t. Time stamps in this form are always considered as UTC (Universal Time Coordinated, basis for calculating worldwide time specifications; the UTC reference time is based on Greenwich Mean Time, GMT, but is not a time zone; it has no daylight saving time or summer time) time stamps when processed with the corresponding statements. You use the statement GET TIME STAMP to create a time stamp that represents the current UTC reference time.
Example
DATA: BEGIN OF wa ,
...
time_stamp TYPE timestampl,
...
END OF wa.
...
GET TIME STAMP FIELD wa-time_stamp.
INSERT dbtab FROM wa.
Determining the current time stamp in the long form and using it to log the point in time, at which a row is inserted into a database table.
For the short and long form of time stamps, the data types TIMESTAMP and TIMESTAMPL are available in the ABAP Dictionary. The respective ABAP types are p of length 8 without fractional portion (short form) and p of length 11 with seven fractional portionss (long form). Time stamps are stored in the format stated above in data objects of these types. Thus the decimal places before the decimal separator represent the date and the time and the fractional portion in the long form represents the fractions of seconds. In programs for which the program attribute Fixed point arithmetic is not set, you must beware of the special rules applying for the data type p.
Time stamps can be used to log points in time and to compare them. They are not suited for direct calculations or for date and time output. For calculations and display, you can convert time stamps into date and time fields of local time zones using the CONVERT TIME STAMP statement, or vice versa using the CONVERT DATE statement. For output to lists, you can use addition TIME ZONE of the WRITE statement. As of release 6.20, the system class CL_ABAP_TSTMP provides methods for adding, subtracting, converting and comparing time stamps. Note that when assigning time stamps in the long form to time stamps in the short form, undesired rounding effects are possible. Direct comparisons of time stamps in the long form with the short form are only possible if the program attribute Fixed point arithmetic is set. Otherwise, you must use system class CL_ABAP_TSTMP for comparisons as well.
The conversion of the UTC reference time of a time stamp into the local time zone of an SAP system or a user is based on a set of rules stored in database tables. The names of the respective tables start with TTZ. The following database tables, whose content you can maintain using transaction STZBD, are relevant for time stamps:
The database table TTZZ contains in column TZONE a list of possible time zones. The entries in the columns ZONERULE and DSTRULE refer to the rules for the time difference of the time zone to the UTC reference time in table TTZR and to the rules for summer time in the tables TTZD, TTZDF and TTZDV.
- The database table TTZR contains in column ZONERULE a list of possible rules for the time difference between time zones and the UTC reference time. The columns UTCDIFF and UTCSIGN contain the time differences to UTC and their signs without consideration of the summer time.
- The database table TTZD contains in column DSTRULE a list of all possible summer time rules. Column DSTDIFF contains the time difference between summer and winter time.
- The database table TTZDF contains in column DSTRULE a list of fixed summer time rules. Column YEARACT contains year numbers for every year for which the rule applies. The columns DATEFROM, TIMEFROM, DATETO and TIMETO contain date and time for beginning and end of the summer time.
- The database table TTZDV contains in column DSTRULE a list of variable summer time rules. Column YEARFROM contains year numbers for every rule, saying in which year the rule applies. The columns MONTHFROM, WEEKDFROM, WEEKDCFROM, TIMEFROM, MONTHTO, WEEKDTO, WEEKDCTO and TIMETO contain month, week, day and time for beginning and end of the summer time.
For a correct set of rules, all rules specified in TTZZ for the time difference between time zones and the UTC reference time in TTZR and all rules specified for the summer time must be contained in TTZD. If the time difference between summer and winter time in TTZD is not equal to 0, the respective summer time rule must be contained in at least one of the tables TTZDF or TTZDV. While TTZDF contains fixed date specifications for the conversion, the date in TTZDV is variable, because a day in a particular week of a month is specified. The system always checks TTZDF first for the summer time rule and then TTZDV.
If in a time zone a summer time rule with a summer time difference not equal to 0 is defined, beware of the following:
- If during summer time a new year starts (in the southern hemisphere), then the year specified in the database tables TTZDF or TTZDV identifies the beginning of the summer time, while the end lies in the following year.
- The time specified for the beginning of summer time in the tables TTZDF and TTZDV identifies the time at which in the ending winter time the clock is put forward by the summer time difference. The first second of summer time is the time you get when you add the summer time difference to the specified time. At the summer time beginning, a time interval of the length of the summer time difference is created, for which you can formulate a date and time specification, but which does not exist as a local time and which cannot be assigned to an UTC reference time. Such a local time specification is treated in the CONVERT DATE statement as an invalid time specification.
- The time specified in the data base tables TTZDF or TTZDV for the end of summer time identifies the time at which in the ending summer time the clock is put backward by the summer time difference. The first second of the winter time is the time you get when you subtract the summer time difference from the specified time.
At the summer time end, a time interval of a length of the summer time difference is created, which is passed twice as a local time (thedouble hour). If you formulate a date and time specification for this interval, the statement CONVERT DATE by default treats it as a time specification for summer time.
Examples
DATA: time_stamp TYPE timestamp,
dat TYPE d,
tim TYPE t,
tz TYPE ttzz-tzone,
dst (1) TYPE c.
tz = ' BRAZIL'.
time_stamp = 20030309033000.
CONVERT TIME STAMP time_stamp TIME ZONE tz
INTO DATE dat TIME tim DAYLIGHT SAVING TIME dst.
WRITE: /(10) dat, (8) tim, dst.
time_stamp = 20030309043000.
CONVERT TIME STAMP time_stamp TIME ZONE tz
INTO DATE dat TIME tim DAYLIGHT SAVING TIME dst.
WRITE: /(10) dat, (8) tim, dst.
For the "BRAZIL" time zone available in database table TTZZ, a shift of -3 hours against the UTC reference time is entered in database table TTZR. The end of the summer time is defined in database table TTZDV as the second Sunday in March at 02:00, which in the year 2003 corresponds to March 9th. With these settings in the rules, the two conversions above both result in the same local time of "01:30:00". The first conversion shows that the time given there is still in the summer time (from Release 6.20).
DATA: time_stamp TYPE timestamp,
dat TYPE d,
tim TYPE t,
tz TYPE ttzz-tzone.
tz = ' BRAZIL'.
dat = '20030309'.
tim = '013000'.
CONVERT DATE dat TIME tim DAYLIGHT SAVING TIME 'X'
INTO TIME STAMP time_stamp TIME ZONE tz.
WRITE: / time_stamp.
CONVERT DATE dat TIME tim DAYLIGHT SAVING TIME ' '
INTO TIME STAMP time_stamp TIME ZONE tz.
WRITE: / time_stamp.
Here, by specifying the summer and winter time explicitly (as of Release 6.20), two different UTC time stamps "20030309033000" and "20030309043000" are created from one local time specification. Without the addition DAYLIGHT SAVING TIME, the UTC time stamp "20030309033000" is created.
