Skip to Content

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.

To report this post you need to login first.

39 Comments

You must be Logged on to comment or reply to a post.

  1. Subramanian Venkateswaran
    This could be very very useful, as currently task at hand, deals in counting the number of weeks per month…

    Would also be useful, if some Function Modules, were mentioned, (of course, we cannot be spoonfed), LAST_WEEK, NEXT_WEEK, GET_WEEK_INFO_BASED_ON_DATE,etc.. Aah the list is numerous.

    Regards,
    Subramanian V.

    (0) 
    1. Horst Keller Post author
      Sure, there are thousands of function modules written by the applications. I’m working in the technology department in the root ABAP-based SAP systems, meaning that our systems are delivered to application development and those systems are delivered to customers. None of the function modules you mentioned are available in the root systems. I’m just a poor ABAP guy and can only tell you what the language and the language related classes and function modules can do for you.

      Cheers

      Horst

      (0) 
    2. Thomas Szücs
      There is function pool SCAL with function modules like DATE_COMPUTE_DAY, DATE_GET_WEEK or WEEK_GET_FIRST_DAY. Good thing is they are avaialble within all systems. There is also the reuse library (transaction se83) where you can find alot more references to useful time and date function modules that are part of all SAP systems.
      (0) 
  2. Subramanian Venkateswaran
    This could be very very useful, as currently task at hand, deals in counting the number of weeks per month…

    Would also be useful, if some Function Modules, were mentioned, (of course, we cannot be spoonfed), LAST_WEEK, NEXT_WEEK, GET_WEEK_INFO_BASED_ON_DATE,etc.. Aah the list is numerous.

    Regards,
    Subramanian V.

    (0) 
    1. Horst Keller Post author
      Sure, there are thousands of function modules written by the applications. I’m working in the technology department in the root ABAP-based SAP systems, meaning that our systems are delivered to application development and those systems are delivered to customers. None of the function modules you mentioned are available in the root systems. I’m just a poor ABAP guy and can only tell you what the language and the language related classes and function modules can do for you.

      Cheers

      Horst

      (0) 
    2. Thomas Szücs
      There is function pool SCAL with function modules like DATE_COMPUTE_DAY, DATE_GET_WEEK or WEEK_GET_FIRST_DAY. Good thing is they are avaialble within all systems. There is also the reuse library (transaction se83) where you can find alot more references to useful time and date function modules that are part of all SAP systems.
      (0) 
  3. Subramanian Venkateswaran
    This could be very very useful, as currently task at hand, deals in counting the number of weeks per month…

    Would also be useful, if some Function Modules, were mentioned, (of course, we cannot be spoonfed), LAST_WEEK, NEXT_WEEK, GET_WEEK_INFO_BASED_ON_DATE,etc.. Aah the list is numerous.

    Regards,
    Subramanian V.

    (0) 
    1. Horst Keller Post author
      Sure, there are thousands of function modules written by the applications. I’m working in the technology department in the root ABAP-based SAP systems, meaning that our systems are delivered to application development and those systems are delivered to customers. None of the function modules you mentioned are available in the root systems. I’m just a poor ABAP guy and can only tell you what the language and the language related classes and function modules can do for you.

      Cheers

      Horst

      (0) 
    2. Thomas Szücs
      There is function pool SCAL with function modules like DATE_COMPUTE_DAY, DATE_GET_WEEK or WEEK_GET_FIRST_DAY. Good thing is they are avaialble within all systems. There is also the reuse library (transaction se83) where you can find alot more references to useful time and date function modules that are part of all SAP systems.
      (0) 
  4. Tatjana Lenz
    Hi. Don’t know if this is the right place to pose this question but here goes:-

    How do you read the system time zone?

    Now you have the current system date (sy-datum)and time (sy-uzeit) and the offset from GMT/ UTC time WITHOUT the summer time(sy-tzone). OK so it’s possible to calculate the time offset from UTC time and look up tables TTZR and TTZZ to find the time
    zone WITHOUT taking account of the daylight savings.

    If you are currently on summertime daylight savings (indicated by flag sy-dayst) you can get the summertime time offset by doing a bit of math with sy-datum and sy-uzeit and then look up table TTZD to get the summertime rule. From this you can again look up table TTZZ and have a pretty accurate stab at the system time zone.

    Now my question is this:- when you are on winter time, how can you accurately get the system time zone, because there is no way to calculate the summertime offset from
    sy-datum and sy-uzeit ?

    I would really appreciate a response. Even if it is to tell me to post somewhere else.

    Thank you.

    (0) 
    1. Mark Finnern
      Hi Tatjana,

      Yes such a question is better posted to the SDN forums. For example the ABAP forum: ABAP Development

      The advantage is that you can give a little thank you in form of points for the SDNers that helped you.

      Please post your question there.

      Best, Mark.

      (0) 
  5. Tatjana Lenz
    Hi. Don’t know if this is the right place to pose this question but here goes:-

    How do you read the system time zone?

    Now you have the current system date (sy-datum)and time (sy-uzeit) and the offset from GMT/ UTC time WITHOUT the summer time(sy-tzone). OK so it’s possible to calculate the time offset from UTC time and look up tables TTZR and TTZZ to find the time
    zone WITHOUT taking account of the daylight savings.

    If you are currently on summertime daylight savings (indicated by flag sy-dayst) you can get the summertime time offset by doing a bit of math with sy-datum and sy-uzeit and then look up table TTZD to get the summertime rule. From this you can again look up table TTZZ and have a pretty accurate stab at the system time zone.

    Now my question is this:- when you are on winter time, how can you accurately get the system time zone, because there is no way to calculate the summertime offset from
    sy-datum and sy-uzeit ?

    I would really appreciate a response. Even if it is to tell me to post somewhere else.

    Thank you.

    (0) 
    1. Mark Finnern
      Hi Tatjana,

      Yes such a question is better posted to the SDN forums. For example the ABAP forum: ABAP Development

      The advantage is that you can give a little thank you in form of points for the SDNers that helped you.

      Please post your question there.

      Best, Mark.

      (0) 
  6. Tatjana Lenz
    Hi. Don’t know if this is the right place to pose this question but here goes:-

    How do you read the system time zone?

    Now you have the current system date (sy-datum)and time (sy-uzeit) and the offset from GMT/ UTC time WITHOUT the summer time(sy-tzone). OK so it’s possible to calculate the time offset from UTC time and look up tables TTZR and TTZZ to find the time
    zone WITHOUT taking account of the daylight savings.

    If you are currently on summertime daylight savings (indicated by flag sy-dayst) you can get the summertime time offset by doing a bit of math with sy-datum and sy-uzeit and then look up table TTZD to get the summertime rule. From this you can again look up table TTZZ and have a pretty accurate stab at the system time zone.

    Now my question is this:- when you are on winter time, how can you accurately get the system time zone, because there is no way to calculate the summertime offset from
    sy-datum and sy-uzeit ?

    I would really appreciate a response. Even if it is to tell me to post somewhere else.

    Thank you.

    (0) 
    1. Mark Finnern
      Hi Tatjana,

      Yes such a question is better posted to the SDN forums. For example the ABAP forum: ABAP Development

      The advantage is that you can give a little thank you in form of points for the SDNers that helped you.

      Please post your question there.

      Best, Mark.

      (0) 
  7. Jayanta Choudhuri
    SAP needs to reveal more about its hugely useful FMs. JAVA has public API and so does .NET. Where is SAP’s public API for small things? BAPIs are bigtime? http://ifr.sap.com is in shutdown mode.

    I saved a huge amount of pain by using FM CCU_TIMESTAMP_DIFFERENCE which gives difference between 2 time stamps.

    Similarly FM ROUND does job of TRUNC & ROUND and is a good example of generics.

    Why does a poor ABAPer need to hunt in SE37?
    TFTIT has descriptions in DE only for most FMs. Which leaves EN people neglected! SAP SE16 has only case sensitive search. Thus to find Round you need to try *Round* as well as *round*.

    We hunt in SE24 and in SE37 and in SE16. A nice EN API tree of CLs & FMs would be the best gift SAP can give the ABAP Community.

    (0) 
  8. Jayanta Choudhuri
    SAP needs to reveal more about its hugely useful FMs. JAVA has public API and so does .NET. Where is SAP’s public API for small things? BAPIs are bigtime? http://ifr.sap.com is in shutdown mode.

    I saved a huge amount of pain by using FM CCU_TIMESTAMP_DIFFERENCE which gives difference between 2 time stamps.

    Similarly FM ROUND does job of TRUNC & ROUND and is a good example of generics.

    Why does a poor ABAPer need to hunt in SE37?
    TFTIT has descriptions in DE only for most FMs. Which leaves EN people neglected! SAP SE16 has only case sensitive search. Thus to find Round you need to try *Round* as well as *round*.

    We hunt in SE24 and in SE37 and in SE16. A nice EN API tree of CLs & FMs would be the best gift SAP can give the ABAP Community.

    (0) 
  9. Jayanta Choudhuri
    SAP needs to reveal more about its hugely useful FMs. JAVA has public API and so does .NET. Where is SAP’s public API for small things? BAPIs are bigtime? http://ifr.sap.com is in shutdown mode.

    I saved a huge amount of pain by using FM CCU_TIMESTAMP_DIFFERENCE which gives difference between 2 time stamps.

    Similarly FM ROUND does job of TRUNC & ROUND and is a good example of generics.

    Why does a poor ABAPer need to hunt in SE37?
    TFTIT has descriptions in DE only for most FMs. Which leaves EN people neglected! SAP SE16 has only case sensitive search. Thus to find Round you need to try *Round* as well as *round*.

    We hunt in SE24 and in SE37 and in SE16. A nice EN API tree of CLs & FMs would be the best gift SAP can give the ABAP Community.

    (0) 
  10. Raj Sam
    Hi,

    I am looking take care of my SAP System. You have mentioned that from Database Server, ABAP runtime takes time.

    Does the database takes time stamp from O/S ?

    Also, does any application program need any changes due to change in Daylight saving date changed in USA?

    I am Basis guy..

    Thanks,
    Sam

    (0) 
  11. Raj Sam
    Hi,

    I am looking take care of my SAP System. You have mentioned that from Database Server, ABAP runtime takes time.

    Does the database takes time stamp from O/S ?

    Also, does any application program need any changes due to change in Daylight saving date changed in USA?

    I am Basis guy..

    Thanks,
    Sam

    (0) 
  12. Raj Sam
    Hi,

    I am looking take care of my SAP System. You have mentioned that from Database Server, ABAP runtime takes time.

    Does the database takes time stamp from O/S ?

    Also, does any application program need any changes due to change in Daylight saving date changed in USA?

    I am Basis guy..

    Thanks,
    Sam

    (0) 
  13. Monika Wieland
    As you explained above, the GET TIME Command updates SY-DATUM and SY-UZEIT but not SY-DAYST which also refers to system time information as well as SY-DATUM and SY-UZEIT.
    Wouldn’t this, on change from summer to winter-time, during the duplicate hour produce inconsistent Information: See the Scenario:
    A Program starts at the end of the first of duplicate hours. The value of SY-DAYST is ‘X’. Now the second of duplicate hours begins. A GET TIME Command will update SY-DATUM and SY-UZEIT but not SY-DAYST which still contains ‘X’ – a now wrong information referring to the current value of SY-UZEIT!
    (0) 
    1. Horst Keller Post author
      Hi Monika,

      principally you’re right, but in fact your scenario is not valid, since SAP still demands a system shut down during the change of DST to non-DST and vice versa.

      For which purpose do you need SY-DAYST? We regard it as kind of obsolete and don’t have an idea what to use it for.

      Best regards

      Horst

      (0) 
  14. Monika Wieland
    As you explained above, the GET TIME Command updates SY-DATUM and SY-UZEIT but not SY-DAYST which also refers to system time information as well as SY-DATUM and SY-UZEIT.
    Wouldn’t this, on change from summer to winter-time, during the duplicate hour produce inconsistent Information: See the Scenario:
    A Program starts at the end of the first of duplicate hours. The value of SY-DAYST is ‘X’. Now the second of duplicate hours begins. A GET TIME Command will update SY-DATUM and SY-UZEIT but not SY-DAYST which still contains ‘X’ – a now wrong information referring to the current value of SY-UZEIT!
    (0) 
    1. Horst Keller Post author
      Hi Monika,

      principally you’re right, but in fact your scenario is not valid, since SAP still demands a system shut down during the change of DST to non-DST and vice versa.

      For which purpose do you need SY-DAYST? We regard it as kind of obsolete and don’t have an idea what to use it for.

      Best regards

      Horst

      (0) 
  15. Monika Wieland
    As you explained above, the GET TIME Command updates SY-DATUM and SY-UZEIT but not SY-DAYST which also refers to system time information as well as SY-DATUM and SY-UZEIT.
    Wouldn’t this, on change from summer to winter-time, during the duplicate hour produce inconsistent Information: See the Scenario:
    A Program starts at the end of the first of duplicate hours. The value of SY-DAYST is ‘X’. Now the second of duplicate hours begins. A GET TIME Command will update SY-DATUM and SY-UZEIT but not SY-DAYST which still contains ‘X’ – a now wrong information referring to the current value of SY-UZEIT!
    (0) 
    1. Horst Keller Post author
      Hi Monika,

      principally you’re right, but in fact your scenario is not valid, since SAP still demands a system shut down during the change of DST to non-DST and vice versa.

      For which purpose do you need SY-DAYST? We regard it as kind of obsolete and don’t have an idea what to use it for.

      Best regards

      Horst

      (0) 
  16. Alon Raskin
    The DAYLIGHT SAVING TIME addition to the convert command doesnt make much sense to me. If I provide a dat and tim that are in Winter but I set DAYLIGHT SAVING TIME to ‘X’ then i get a sy-subrc = 12. If the command knows when DST is (based on those TZ* tables) then whats the point of this addition? Why doesnt the CONVERT command just look up whether the dat/tim are in DST and adjust accordingly.

    I know I must be missing something.

    Regards,

    Alon

    (0) 
    1. Horst Keller Post author
      Hi Alon,

      Your friend, the ABAP documentation, (http://help.sap.com/abapdocu_70/en/ABENTIME-STAMP-GENERAL.htm) says:

      CONVERT DATE:

      Specifying daylight saving and winter time after DAYLIGHT SAVING TIME enables you to create different UTC time stamps from matching local time stamps within the extra hour when switching from daylight saving to winter time.

      CONVERT TIME STAMP:

      It is possible to use the return value for the summer time in dst to differentiate between duplicate local time specifications that occur when UTC time stamps are converted into local time during the double hour in the changeover between summer and winter time.

      So, it’s useful during that infamous extra or double hour when times are switched.

      Best regards

      Horst

      (0) 
  17. Alon Raskin
    The DAYLIGHT SAVING TIME addition to the convert command doesnt make much sense to me. If I provide a dat and tim that are in Winter but I set DAYLIGHT SAVING TIME to ‘X’ then i get a sy-subrc = 12. If the command knows when DST is (based on those TZ* tables) then whats the point of this addition? Why doesnt the CONVERT command just look up whether the dat/tim are in DST and adjust accordingly.

    I know I must be missing something.

    Regards,

    Alon

    (0) 
    1. Horst Keller Post author
      Hi Alon,

      Your friend, the ABAP documentation, (http://help.sap.com/abapdocu_70/en/ABENTIME-STAMP-GENERAL.htm) says:

      CONVERT DATE:

      Specifying daylight saving and winter time after DAYLIGHT SAVING TIME enables you to create different UTC time stamps from matching local time stamps within the extra hour when switching from daylight saving to winter time.

      CONVERT TIME STAMP:

      It is possible to use the return value for the summer time in dst to differentiate between duplicate local time specifications that occur when UTC time stamps are converted into local time during the double hour in the changeover between summer and winter time.

      So, it’s useful during that infamous extra or double hour when times are switched.

      Best regards

      Horst

      (0) 
  18. Alon Raskin
    The DAYLIGHT SAVING TIME addition to the convert command doesnt make much sense to me. If I provide a dat and tim that are in Winter but I set DAYLIGHT SAVING TIME to ‘X’ then i get a sy-subrc = 12. If the command knows when DST is (based on those TZ* tables) then whats the point of this addition? Why doesnt the CONVERT command just look up whether the dat/tim are in DST and adjust accordingly.

    I know I must be missing something.

    Regards,

    Alon

    (0) 
    1. Horst Keller Post author
      Hi Alon,

      Your friend, the ABAP documentation, (http://help.sap.com/abapdocu_70/en/ABENTIME-STAMP-GENERAL.htm) says:

      CONVERT DATE:

      Specifying daylight saving and winter time after DAYLIGHT SAVING TIME enables you to create different UTC time stamps from matching local time stamps within the extra hour when switching from daylight saving to winter time.

      CONVERT TIME STAMP:

      It is possible to use the return value for the summer time in dst to differentiate between duplicate local time specifications that occur when UTC time stamps are converted into local time during the double hour in the changeover between summer and winter time.

      So, it’s useful during that infamous extra or double hour when times are switched.

      Best regards

      Horst

      (0) 

Leave a Reply