About Timestamps

A timestamp is a sequence of characters or encoded information identifying when a certain event occurred, usually giving date and time of day, sometimes accurate to a small fraction of a second.

(Wikipedia, August 29, 2016).

In ABAP you get a timestamp accurate to a second with the statement

GET TIME STAMP FIELD DATA(ts).

cl_demo_output=>display( ts ).

Here ts has the dictionary type TIMESTAMP and the result might look like 20160829131515.

And a timestamp accurate to a small fraction of a second with:

DATA ts TYPE timestampl.

GET TIME STAMP FIELD ts.

cl_demo_output=>display( ts ).

The result might look like 20160829131612.294638.

Those are are POSIX timestamps that are independent of a time zone.

The format of such  ABAP timestamps is YYYYMMDDHHMMSS.fffffff with 7 fractions of a second in case of type TIMESTAMPL.

As a rule, you use such timestamps to mark data with – well – timestamps (time of creation, time of update, …).

In order to handle timestamps, you can do the following:

• You can directly compare different timestamps of the same type:

  GET TIME STAMP FIELD DATA(ts2).
  WAIT UP TO 1 SECONDS.
  GET TIME STAMP FIELD DATA(ts1).
  ASSERT ts2 < ts1.

• You can convert timestamps into date and time fields of a time zone:

    GET TIME STAMP FIELD DATA(ts).

    CONVERT TIME STAMP ts TIME ZONE sy-zonlo

            INTO DATE DATA(date) TIME DATA(time)

            DAYLIGHT SAVING TIME DATA(dst).

     cl_demo_output=>display( |{ date }\n{

                                 time }\n{

                                 dst } | ).

         Giving something like 20160829, 172223, X

• You can format timestamps in string processing:

  GET TIME STAMP FIELD DATA(ts).

  cl_demo_output=>display( |{ ts TIMESTAMP = ISO } | ).
  
  Giving something like 2016‑08‑29T15:27:29

• You can serialize/deserialize timestamps, if their datatype refers to a special domain:

  DATA ts TYPE xsddatetime_z.
  GET TIME STAMP FIELD ts.
  
  CALL TRANSFORMATION id SOURCE ts = ts
                 RESULT XML DATA(xml).
  cl_demo_output=>display_xml( xml ).

  Giving something like: <TS>2016‑08‑29T15:33:50Z</TS>

• You can do some simple calculations with the methods of class CL_ABAP_TSTMP:

  DATA: ts1 TYPE timestampl,

          ts2 TYPE timestampl.

    GET TIME STAMP FIELD ts2.

    WAIT UP TO 1 SECONDS.

    GET TIME STAMP FIELD ts1.

    DATA(seconds) = cl_abap_tstmp=>subtract(

        EXPORTING

          tstmp1 = ts1

          tstmp2 = ts2 ).

    cl_demo_output=>display( seconds ).

     Giving something like 1.001369.

And that is it. Timestamps are not foreseen for more and you cannot do more! Especially, you should never do direct calculations with timestamps itself:

GET TIME STAMP FIELD DATA(ts1).

DATA(ts2) = cl_abap_tstmp=>add(

                tstmp = ts1

                secs  = 3600 ).

cl_demo_output=>display( ts2 – ts1 ).

The result is 10000. How that?

Well, you should know it. Timestamps don’t have an own built-in ABAP type. In another ABAP world, in NGAP, that is Release 8.x, in fact they have and we wouldn’t have to bother. But in the 7.02/7.30-7.40-7.50 Release line, timestamps are stored in type p numbers:

• p length 8 without decimal places for dictionary type TIMESTAMP
• p length 11 with seven decimal places for dictionary type TIMESTAMPL.

This is different to data fields of type d and time fields of type t. Those have a special meaning and are treated specially at different operand positions (either as character strings or as numbers that denote days or seconds).

With exception of the statements and methods listed above, ABAP does not recognize the semantical meaning of a timestamp. It simply treats it as a packed number of the given value. With other words, if ts1 in the last example is 20160829160257, adding 3600 seconds using the method ADD gives 20160829170257 in ts2. You see the difference? One hour later (17 compared to 16) when interpreted in the timestamp format, but a difference of 100000 when interpreted as the normal value format for type p.

Recently, I’ve also seen something as follows (and that’s the reason for this blog):

GET TIME STAMP FIELD DATA(ts).

ts = ts + 86400 * 2 + 3600 * 3.

Someone believed that ABAP timestamps are handled like a number of seconds and wanted to add 2 days and 3 hours. No, no, no. If ts again is 20160829160257, you simply add 86400 * 2 + 3600 * 3 to that number and you get 20160832943857. That is even not a valid timestamp!

Using type p for timestamps instead of a character type is simply a convenient and efficient way of storing timestamps with decimal places.But never, never, never tend to believe that you can do something meaningful with the type p number directly!