(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:
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
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:
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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
4 | |
2 | |
2 | |
2 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |