Another way to get an interval is to use an interval expression:

select round(extract(minute from (start_date - end_date) day to second) / 60, 1) 
from round_test

Please note that if the number of minutes is 57 or more, the result will be 1, meaning 1 hour. What is the greatest time difference you need to handle, and what result do you want to see in that case?

You probably chose the simplest example to illustrate the problem, but that may mislead us into thinking all your cases are equally simple. You need to clarify if all your differences will be less than one hour (I assume not), and also whether your "date" values may have non-zero "seconds" components (I assume yes, although in your simplified example they do not). Chris's and Stew's solutions would have to be adjusted for both possibilities - difference greater than 1 hour, and non-zero seconds components. The formulas will become quite messy; the double-rounding seems much cleaner by comparison. (In addition, it is not clear a priori that dividing by 60 rather than 86400 may not lead to the same kind of rounding errors in the results - it's certainly less likely, but not impossible, at least not without a good argument or a lot of testing.)

Note that rounding to 3 places first works in your case, but only because 0.1 hours (6 minutes) is less than 1000 seconds. If instead of integer multiples of 6 minutes you were interested in integer multiples of 24 minutes, or 45 minutes, the first rounding should consider more decimal places, if the "seconds" component isn't always zero. I won't discuss this further since it's not your use case, but something to be aware of nevertheless; the magic number "3" you chose for the first rounding works, but only for a very specific reason.

As to "best practice", I would say "documentation" is probably the right option. A brief comment in the query itself, explaining that the double-rounding corrects for rounding errors (you may even include a specific example: Oracle computes (2340/86400) * 24 = 0.6499999999999999999999999999999999999992 rather than 0.65, which is the correct value - this is your "39 minutes difference" case and illustrates why you need two roundings), as well as a more detailed explanation in the code documentation, if your organization follows that practice.

Mathguy, you say: "Chris's and Stew's solutions would have to be adjusted for both possibilities - difference greater than 1 hour, and non-zero seconds components."

- For the difference greater than 1 hour, I did mention that, which it would have been more polite to acknowledge.
- The non-zero seconds are not an issue in this case, since 1/10 of an hour is exactly 6 whole minutes, so the boundaries are at whole minutes: 3, 9, 15, 21 and so on. I did test non-zero seconds anyway.

"The formulas will become quite messy"

How messy depends on whether the difference can be 24 hours or more, which was the point of my question.

"..it is not clear a priori that dividing by 60 rather than 86400 may not lead to the same kind of rounding errors in the results"

I tested all intervals from 0 seconds to 59 minutes and 59 seconds, and I found this result at 2 minutes and 59 seconds:

with dates as (
  select sysdate start_date, sysdate - interval '2:59' minute to second end_date
  from dual
)
select round(extract(minute from (start_date - end_date) day to second) / 60, 1) hr,
round(round((start_date - end_date) * 24, 3), 1) as double_round
from dates

        HR DOUBLE_ROUND
---------- ------------
         0 .1          

I'll leave you all to decide which result is correct.

After further testing, it appears that the "double round" solution gets the same result as the "interval" solution if the inner round integer parameter is between 4 and 38.

Oops - I used the wrong logic in my comment.

The "rounding" calculations in the OP's attempt are always based on numbers representing hours - not "tens of an hour". As such, what is relevant is that one second is 1/3600 of an hour, so the inner rounding should be to at least four decimal places (1/10000) - precisely in order to avoid the issue Stew encountered: rounding something strictly less than "3 minutes" to only 3 decimal places will exactly equal "3 minutes", and then the further rounding to one decimal place will give the wrong result. The same happens at any "boundary" minus 1 second, and for the same reason.

The inner rounding should be to 4 decimal places (or more - the result will be the same, as Stew also found).

I suppose mathguy considers the interval solutions to be "messy" because they involve multiple uses of the EXTRACT function. I would counter that the interval expression, besides working correctly, is the most self-documenting solution because it says explicitly that a DAY TO SECOND interval is being used. It also states explicitly the logic used to convert each component to a value in hours, whereas the date-based solution requires understanding of Oracle date arithmetic and of an obscure workaround.

When possible and convenient, an inline view could of course limit the tedious repetition of the same code:

with data as (select (start_date - end_date) day to second ids from round_test)
select
  extract(day from ids) * 24 +
  extract(hour from ids) +
  round(extract(minute from ids) / 60, 1) hours
from data

P.S. Funny that no one has mentioned the fact that start_date is later than end_date :-)