1

I have a list of events and each one has a startDate and endDate. I need to know the average time taken for each event.

I need something like this:

select sum ( (timestamp(startDate) -  timestamp(endDate)) for each event )
       / (count of events)
WarrenT
  • 4,502
  • 19
  • 27
User
  • 573
  • 3
  • 15
  • 28
  • What platform are you on - iSeries, LUW, etc? The current answers both use `timestampdiff(...)`, which is going to give an _estimate_ - is this okay for your use, or will you need an "exact" answer? Are there dates you might need to exclude? – Clockwork-Muse Apr 30 '14 at 09:38

2 Answers2

3

It only makes mathematical sense to take the AVG() of a numeric value, not datetime values or durations. Since you want your answer to be in minutes precision, you want to get your difference in minutes, then convert back to days, hours, minutes. (There are 24*60=1440 minutes in a standard day.)

with q as
(select avg(
             timestampdiff(4, char(endDate - startDate) )
           )  as avgmns
  from yourChosenData
)
select int(avgmns / 1440) as avg_days,
       int( mod(avgmns,1440) / 60) as avg_mins,
       mod(avgmns, 60) as avg_secs
  from q

As mentioned below, timestampdiff() is an estimate. To avoid this issue, one could use a more accurate calculation.

with q as
(select avg(
             ( days(endDate) - days(startDate) ) * 1440
           + ( midnight_seconds(endDate) - midnight_seconds(startDate) ) / 60
           )  as avgmns
  from yourChosenData
)
select int(avgmns / 1440) as avg_days,
       int( mod(avgmns,1440) / 60) as avg_mins,
       mod(avgmns, 60) as avg_secs
  from q

In order to address the DST issue, if needed, one might choose either of:

  • include a UTC offset column corresponding to each timestamp field. This would also be useful if timstamps were being recorded in more than one timezone. The diference in offsets could then be fed into the calculation along with the timestamps.
  • provide a deterministic UDF which could return a UTC or DST adjustment offset for a given timestamp. If multiple timezones are involved, then the zone should also be a parameter to the function. Depending on the geographic areas involved, the logic may also need to consider areas which observe alternative DST rules.
WarrenT
  • 4,502
  • 19
  • 27
  • Except timestampdiff() returns an estimate - 30-day months, 365-day years, and it ignores DST. Depending on the resolution chosen and the actual distance between the dates, this could become significant. – Clockwork-Muse Apr 30 '14 at 09:30
  • Thanks Warren for your reply :) Actually the second query calculate the difference considering the days only and am concerning with the full time to the seconds – User May 05 '14 at 13:01
1

You have to be careful of the denominator to prevent a 0 division: SQL0802 - Data Conversion or Data Mapping Error

Depending on the precision of the results, you will need to convert the date. Let's suppose you need seconds (2)

select 
  sum ( timestampdiff(2, endDate - startDate))
  /
  sum (count of events)
from yourTable

http://pic.dhe.ibm.com/infocenter/db2luw/v10r5/topic/com.ibm.db2.luw.sql.ref.doc/doc/r0000861.html

Community
  • 1
  • 1
AngocA
  • 7,655
  • 6
  • 39
  • 55
  • Thanks AnfocA for your reply :) I need the result to be in days / hours/minutes – User Apr 29 '14 at 15:27
  • In that case, you need to run the comparison for days (16), hours (8) and minutes (4). There is not a function that returns this information. – AngocA Apr 29 '14 at 15:37
  • Actually, when you do a difference between two date, db2 returns a string that represents the difference in years, months, days, hours, minutes, seconds (point) microseconds – AngocA Apr 29 '14 at 15:47
  • The difference is returned as a numeric value, a "duration", which you must convert to character for `timestampdiff()`. But it would not be mathematically correct to take the average of those YYYYMMDDhhmmss.nnnnnn duration values. – WarrenT Apr 30 '14 at 01:08
  • 1
    The other problem is that `timestampdiff()` returns an **estimate** - 30-day months, 365-day years, and it ignores DST. Depending on the resolution chosen and the actual distance between the dates, this could become significant. – Clockwork-Muse Apr 30 '14 at 09:24