Skip to Content

Performance improvement hints: date, time, timestamps

To glue date and time to a timestamp or to split a timestamp into date and time it is possible to do this in a various ways. (By “glue” I mean to create a timestamp out of a date and a time so the time zone stays the same and by “split” I mean to split up a timestamp so a date and a time is created with the same time zone; So this blog concentrates on no time zones…if you need time zone conversion, you have to use CONVERT) I show which one takes which time.

From date and time to a timestamp

via convert date time

via concatenate

via char modification (1)

via char modification (2)

via structure

Comparison of the different types

And now for the comparison of the different types of date and time to timestamp conversions I measured these times:

conversion type time consumed
(no real times)
convert date time 21227
concatenate 2957
char modification (1) 2599
char modification (2) 2727
structure 2594

time comparison (without convert date time)

So this means that we should go for the “char modification (1)” or the “structure” conversion. But what this also means is, that the CONVERT DATE TIME INTO TIME STAMP TIME ZONE is a very very bad idea. Never use CONVERT!
So either do something like this
lv_char14(8) = sy-datum.
lv_char14+8(6) = sy-uzeit.
or something like this
begin of datetimestr,
datum type sydatum,
uzeit type syuzeit,
end of datetimestr.
ls_datetimestr-datum = sy-datum.
ls_datetimestr-uzeit = sy-uzeit.

From timestamp to date and time

To do the split from timestamp to date and time, you can use nearly the same options as above: convert time stamp, char modifications and the structure thing.

via convert time stamp

via char modification

via structure

Comparison of the different types

And now for the comparison of the different types of timestamp to date and time conversions I measured these times:

conversion type time consumed
(no real times)
convert date time 16250
char modification 10665
structure 10287

So this means that we should go for the “char modification (1)” or the “structure” conversion (the difference is not really big). And again never use CONVERT, it is not this bad in this example, but it is bad enough.
So either do something like this
lv_datum = lv_char14(8).
lv_uzeit = lv_char14+8(6).
or something like this
begin of datetimestr,
datum type sydatum,
uzeit type syuzeit,
end of datetimestr.
ls_datetimestr = lv_timestamp.
lv_datum = lv_datetimestr-datum.
lv_uzeit = ls_datetimestr-uzeit.

Code for the measurement

And finally here is the code I used to measure the times (the naming in the coding is different):
(use this to copy and paste in a test report)

…and something at the end on the CONVERT which has nothing to do with performance: please remember that the TIME ZONE is always related to the DATE and TIME parts. The TIME STAMP is always always always in UTC. There is no possibility that you can convert to or from a non-UTC timestamp with CONVERT!

You must be Logged on to comment or reply to a post.
  • Hi Harry,

    I’m surprised that you make a strong statement for not using CONVERT. Most developers agree that you should not try to use smart code constructs to improve performance if
    a) you don’t know if the part you’re changing is really a performance bottleneck, and
    b) the clarity of the coding suffers.

    Personally I don’t believe that one can find a “real-life-ABAP” with a need to remove CONVERT statements because it then will run substantially faster. Of course you can argue about b) given your specific example, but I’d say that CONVERT offers more functionality on handling timestamps (which are actually type P) than just concatenating a date/time.

    Also, a short comment on the performance measurements for the loop statements: As long as we don’t know/consider the actual implementation details of language statements/constructs some differences might not be so surprising.

    For example the “LOOP AT WHERE.” versus “LOOP AT. IF” can probably be explained by data transport: If you do a loop with a where condition the ABAP VM can inspect the condition, but doesn’t need to retrieve/copy the whole table line within each run. Therefore one would actually expect that the “LOOP AT WHERE” should be much better the less lines are actuall read and the longer a table row is. Try a “LOOP ASSIGNING” and you should see an improvement when using long table lines and lots of iterations…

    Cheers, harald

    • Hi Harald,
      Regarding the CONVERT: I only wanted to show that for splitting a timestamp or converting a timestamp to date and time, the CONVERT with ‘UTC’ should not be used. I think in this case the use of CONVERT or the use of an assignment is not a big difference in the clarity of the code.

      Perhaps you are right with the statement that you do not know any coding where the change from CONVERT to an assignment really changes a lot. I won’t propose to change coding, but if you start a new method and you can prevent CONVERT – why not?
      A funny example might be the coding I found in my are: somebody really created a class method to convert one timestamp to another timestamp with different time zones. (Besides the fact that timestamps should always be UTC,) The overhead of calling a method to do two statements is real big for such a small thing – and because this method is called something around 6 times per document (it’s a purchasing document with creation timestamp, changing timestamp and assuming two items with shipping timestamp and delivery timestamp) I think it might be a good hint to know what this all does.

      Of course CONVERT offers a lot more functionality. (Not enough for me, because of the restriction that timestamps are always UTC and the very very strange syntax regarding the TIME ZONE) But I think for UTC-split or UTC-concat, you should use the assignment.

      Regarding the measurements: I tried to be as realistic as possible in the measurements by actually “doing” something in the loop. I already found that in case you do not write-access a structure the loop is faster, but this is not realistic in most of my own real-life loops. The most important things in the loop-blog were: 1) that there is a substantial (means kernel implementation) difference between the two “LOOP AT WHERE” and “LOOP AT. IF” and 2) the proposal to jump to the correct index and then LOOP FROM there. In the last case this might be somewhat unclear coding in the first place, but if you grasp this once it is easy in all cases, because the pattern is always the same.

      Kind regards

      • Hello Harry,
        A great post again Harry, Thanks for highlighting this.

        On the other hand, I kind of agree with Harald.
        If you are only using convert once or twice in a report/application, I think it is fine. You are not going to face a big performance problem.
        But if you have the convert statement repeatedly in a loop, like in your case, and if it does prove to be a bottle-neck then it is advisable to do your own code for this.
        But then readability does suffer !!

        How about other string commands like ‘replace’ or ‘search’ ? I think if we have this in a loop, even this could prove to be a bottle-neck. Would you then want to write your own sub-routine for this also ?

        I am not against your idea, i am just thinking aloud. Because the code behind these SAP commands will be generic enough to consider a lot of conditions/options, and I am just wondering if we should really go and start coding for each of this. Your comments on this, Harry ?


        • It does affect readability – yes. But I saw a database layer for several objects where the timestamps are stored on the database as UTC as it should be, but where the timestamps are provided from the database layer in local time, (which I btw. think is really worse: local timestamp) and all the time when you store or read from database the timestamps are going thru CONVERT two times: once for split and once for the “real” CONVERT into a local time. So because of this I was wondering. And for this conversion a function module was used – and so the conversion could easily be done with something different than CONVERT, because in the function module it is really clear what it should do.
          Perhaps we all hope on an improvement from SAP Basis 🙂