'Is there a reason to subtract 15 seconds while calculating a duration between two decimal times in Crystal Reports 16?
I am almost a complete novice in Crystal Reports 16, but am currently tasked with redeveloping some reports that were left behind when my predecessor retired. The current report includes a formula field which calculates the number of seconds elapsed between two timestamps, which have already been converted into a decimal format (ex: 0.00673611111111111) and is stored in the "timestamp_num" field.
My goal is to recreate the output of this report perfectly using SQL Server Management Studio to ensure that I understand the bones of the report before I really start making wholesale changes in Crystal.
I have gotten to the point where I generally understand what they are doing in the formula (below). Something that I still can't figure out is: why are they checking if the duration is less than 15, and then if it is, why are they subtracting 15 at the end?
IIF(
(Hour(CTime ({table.timestamp_num})) * 3600) + (Minute(CTime ({table.timestamp_num})) * 60) + Second(CTime({table.timestamp_num})) < 15,
(Hour(CTime ({table.timestamp_num})) * 3600) + (Minute(CTime ({table.timestamp_num})) * 60) + Second(CTime({table.timestamp_num})),
(Hour(CTime ({table.timestamp_num})) * 3600) + (Minute(CTime ({table.timestamp_num})) * 60) + Second(CTime({table.timestamp_num})) - 15
)
I have tested calculating the difference between the timestamps in SQL using the DATEDIFF function which works perfectly, other than this mystery 15 second difference.
Is there something I'm missing in the rationale behind calculating durations in Crystal that would necessitate the 15 second subtraction, or is there something else that could explain why they would include this logic?
Solution 1:[1]
Perhaps the logic is attempting to guard against cases where times very close to midnight spill over to the next day due to some strange rounding effect (some interaction between the data type, connectivity driver, and Crystal version).
Test to see what happens when the the time stamp is 1 second before midnight.
Or perhaps they got the logic wrong (reversed) and what they actually wanted to achieve is pushing cases with a few seconds after midnight back into the previous day.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | MilletSoftware |
