inconsistency between month, day, second representation of interval data type

Viewed 170

I understand why postgresql uses month,day and second fields to representate the sql interval datatype. A month is not always the same length and a day can have 23, 24 or 25 hours if a daylight savings time adjustment is involved. this is from postgresql documentation.

But I then do not understand why this is not consequently handled both for months and days. see the following query which calculates an exact interval where the number of seconds between two points in time is exactly calculatable:

select ('2017-01-01'::timestamp-'2016-01-01'::timestamp); -->366 days.

postgresql chooses to give a result in days. not in months and not in seconds.

But why is the result days and not seconds? it is NOT defined how long days are (they can be 23,24 or 25 hours long). so why does he not give output in seconds?

Then since the length of months is also not defined, why doesn't postgresql give an output of 12 month instead of 366 days?

He does not care that the length of days is not defined, but obviously he cares that the length of month is not defined.

Why this asymmetrie?

For further explanation, see this query:

select ('10 days'::interval-'24 hours'::interval); --> 10 days -24:00:00

you see that postgresql correctly refuses to answer with 9 days. He is pretty aware of the problem that days and hours cannot be interchanged. But then again why does the first query return days?

1 Answers
Related