Datetime is not a scalar type. It is a vector type: "A calendar date (day, month, year) and time (hour, minute, second, millisecond) ranging from January 3, 0001, 00:00:00.000 to December 31, 9999, 23:59:59.999"
If you want to know the difference in days between one datetime value and another datetime value, you first convert both datetime values into scalars, the number of days in that date, and then you can use the subtract operator "-" that works with scalars.
Ignoring components other than day, month and year, a datetime value of 17/6/2018 can be approximately converted into a scalar integer value as number of days as
17 + 6 * 12 + 2018 * 365
You can get the year, month, and day as respective integer values from a datetime using functions such as DateTimeMonth(<date>).
I write "approximately" because the simple expression above neglects to correct for leap year and leap century. You don't care about that if your date calculation is within the same year, in which case you can compute using month and day components, or doesn't cross a leap year or leap century boundary, in which case the leap year/century errors wash out as common to both dates.
As to how all the above can be handled, Transact-SQL has a DATEDIFF function that allows you to specify what "boundary" part of a datetime is crossed. DATEDIFF handles leap years correctly but I don't know about leap centuries. It's hard to believe they would have missed that.
In principle, handling leap years and leap centuries in straight SQL without DATEDIFF is not complicated. It just leads to lengthier queries. See, for example, the discussion in
One solution for datetime calculations in 9 would be to implement a SQL Server style DATEDIFF function, ensuring, of course, that it is aware of leap centuries as well as leap years.