Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

A glitch(?) or "feature"(?) in SD_CALC_DURATION_FROM_DATETIME

Former Member
0 Kudos

SD_CALC_DURATION_FROM_DATETIME works fine except for customers who want to be able to enter 24:00:00 as a valid time on a screen field defined with a custom data element that has a "TIMS" type underneath it. (I need the custom data element to get custom F1 documentation help.)

In this case, SD_CALC_DURATION_FROM_DATETIME adds 24 hrs to the calculated duration.

There are, of course, any number of obvious work-arounds but am curious as to why this functions seems to behave this way and if anyone else has noted this glitch(?)/feature(?).

Also, whether there is another function without this feature(?)/glitch(?) that calculates duration to the second ... ????

Thanks in advance for whatever anyone knows about this matter ...

djh

1 ACCEPTED SOLUTION

RichHeilman
Developer Advocate
Developer Advocate
0 Kudos

Not sure why they did that like that. The problem is the export paramter is typed like a decimal field. I certainly wouldn't call it a feature. Anyway here is one work around.



report zrich_0001.

data: e_tdiff type tvro-fahztd.
data: n_tim_temp(6) type n.
data: tim_temp type sy-uzeit.

call function 'SD_CALC_DURATION_FROM_DATETIME'
     exporting
          i_date1          = '20070813'
          i_time1          = '081530'
          i_date2          = '20070813'
          i_time2          = '104545'
     importing
          e_tdiff          = e_tdiff
     exceptions
          invalid_datetime = 1
          others           = 2.

n_tim_temp = e_tdiff .
tim_temp = n_tim_temp.

write:/ e_tdiff, at 20  tim_temp.

Regards,

Rich Heilman

9 REPLIES 9

RichHeilman
Developer Advocate
Developer Advocate
0 Kudos

Not sure why they did that like that. The problem is the export paramter is typed like a decimal field. I certainly wouldn't call it a feature. Anyway here is one work around.



report zrich_0001.

data: e_tdiff type tvro-fahztd.
data: n_tim_temp(6) type n.
data: tim_temp type sy-uzeit.

call function 'SD_CALC_DURATION_FROM_DATETIME'
     exporting
          i_date1          = '20070813'
          i_time1          = '081530'
          i_date2          = '20070813'
          i_time2          = '104545'
     importing
          e_tdiff          = e_tdiff
     exceptions
          invalid_datetime = 1
          others           = 2.

n_tim_temp = e_tdiff .
tim_temp = n_tim_temp.

write:/ e_tdiff, at 20  tim_temp.

Regards,

Rich Heilman

0 Kudos

Nice way of handling the time ....!!

suresh_datti
Active Contributor
0 Kudos

glitch? not sure... if you enter 24:00:00 isn't it supposed to mean end of that day ( ie the 24th hour of the day ) ?

you can check the function module DURATION_DETERMINE too.. it behaves the same way, which I think is correct..

~Suresh

OK.. after reading Rich's response, I realized I didn't get the issue right the 1st time..

I guess the function call DURATION_DETERMINE meets your reqt as there is an option to ge the duration(un typed ) in diff units ie hours,mins,secs etc..

Message was edited by:

Suresh Datti

0 Kudos

Rich/Suresh -

Thanks for the quick responses (I gave 10 and 6 the way I did because Rich was first ... what else can I do?)

The problem here is that the customer wants to be able to enter

8/13/2007 24:00:00

instead of

8/14/2007 00:00:00.

Furthermore, they claim that "in the PM business, there is a "1 second difference" between the two.

I've personally never heard of such a thing but what can you do?

I already have a workaround which preserves the screen behavior the way they want (allowing times of 24:00:00) but adjusting the date/time going into and coming out of the function module.

It's good to know that the other FM does the same thing ... thanks, Suresh.

Dave

0 Kudos

former_member194669
Active Contributor
0 Kudos

Hi,

I think another glitch this fm have is

if you enter a start time of 24:00 on 08.11.2007 and an end time of 01:00 on 08.12.2007.

Then system will give you 25 hours which is wrong.

My suggestion is use fm L_MC_TIME_DIFFERENCE. It will give the result in hours

0 Kudos

Rich -

Thanks for the link - it is interesting.

Hi aRs -

Sorry I wasn't clear - that is the same glitch that I initially mentioned.

Does the FM that you mention (L_MC_TIME_DIFFERENCE) give you back hrs, mins, secs? (Or fractions of hrs up to 3 decimal places?)

Reason I'm asking is that the customer needs minutes and seconds converted to decimal fractions of hours rounded to two decimal places.

That's why I'm using the "SD" function - it returns mins and secs as well as hrs, and I can convert the mins, secs to fractions of hours.

Regards

djh

0 Kudos

Hi,

It will give you in hours only (sorry)

Have you seen the note 1033988 for correction?

aRs

0 Kudos

aRs -

Please look for a second post asking if there's a note on SD_CALC_DURATION_FROM_DATETIME.

When you see it, please respond with the same note number and I'll award 10.

That is what I call invaluable info and I apologize for not having had the time to look for it myself.

But since Suresh and Rich aren't familiar with it either, I don't feel so bad.

Thanks again

djh