postgres '1 year' equals '360 days'?

Question

Am wondering if anyone else has encountered this or knows information about it.

Today is November 3, 2014 and if i check whether or not November 5, 2013 is within the last year i get different answers depending on how i check: 1 year versus 365 days

select now() - '20131105' as diff, 
case when now() - '20131105' <= '1 year' then 'within year' else 'not within year' end as yr_check,
case when now() - '20131105' <= '365 days' then 'within 365 days' else 'not within 365 days' end as day_check

2014-11-03 16:27:38.39669-06;  363 days 16:27:38.39669;  not within year;  within 365 days

Looks like when querying against November 9 tho, it's ok

select now() as right_now, now() - '20131109' as diff, 
case when now() - '20131109' <= '1 year' then 'within year' else 'not within year' end as yr_check,
case when now() - '20131109' <= '365 days' then 'within 365 days' else 'not within 365 days' end as day_check

2014-11-03 16:31:12.464469-06;  359 days 16:31:12.464469;  within year;  within 365 days

anyone have an idea about this? or is there something about date arithmetic that's funny?

postgres version is 9.2.4

Answer 1

or is there something about date arithmetic that's funny?

It's funny alright, but not in the way that makes you laugh.

Twelve months has to equal a year doesn't it?

=> SELECT '12 months'::interval = '1 year'::interval;
 ?column? 
----------
 t

Good. Makes sense. Hmm - wonder how long a month is.

=> SELECT '30 days'::interval = '1 month'::interval;
 ?column? 
----------
 t

Fair enough. Suppose they had to pick something.

Hmm - but that means...

=> SELECT '360 days'::interval = '12 months'::interval;
 ?column? 
----------
 t

Which seems to imply...

=> SELECT '360 days'::interval = '1 year'::interval;
 ?column? 
----------
 t

That can't be right! What they need to do is have a month equal to 30.41666 days. No hang on, what about leap years? Hmm - does this affect weeks? AARGH!

Basically, you can't convert sensibly between time units. There aren't 60 seconds in a minute, or 24 hours in a day, 52 weeks in a year or even 365 days. Unfortunately, humans (particularly customer-shaped humans) like converting between time units so we end up with a mess like this.

PostgreSQL's system is no more loony than any other and in fact is better than most.

Answer 2

I'm not sure what is real problem with this check, but it works other way around:

select now() - interval '1 year' <= date '2013-11-05'

I'm no expert in Postgres, but it can be something with type comparisons, because:

select pg_typeof(now() - date '2013-11-05'),
       pg_typeof(now() - interval '1 year')

yields result:

interval, timestamp with time zone

so your example compares interval with interval, but for different scales - days vs year, and my solution compares timestamp with date, which seems to work

UPDATE:

You can check that interval '1 year' when not attached to year (not added to date or timestamp) equals to 360 days:

select interval '1 year' <= interval '359 days',
       interval '1 year' <= interval '360 days'

which yields:

f, t

From my understanding you can't just compare random year interval when you don't know year it is attached - always compare dates, and just use interval to create new date object.

select now() - interval '1 year' <= now() - interval '365 days'

t

Answer 3

From www.postgresql.org/docs/current/static/datatype-datetime.html:

Internally interval values are stored as months, days, and seconds. This is done because the number of days in a month varies, and a day can have 23 or 25 hours if a daylight savings time adjustment is involved. The months and days fields are integers while the seconds field can store fractions. Because intervals are usually created from constant strings or timestamp subtraction, this storage method works well in most cases. Functions justify_days and justify_hours are available for adjusting days and hours that overflow their normal ranges.

Because you compare two intervals, PostgreSQL internally normalizes values (like justify_interval()), before comparing:

SELECT INTERVAL '31 days' > INTERVAL '1 mon' -- yields 't'

But, if you apply interval substraction/addition, varying day & month length taken into consideration:

SELECT (timestamptz '2014-11-03 00:00:00 America/New_York' - INTERVAL '1 day') AT TIME ZONE 'America/New_York',
       timestamptz '2014-11-03 00:00:00 America/New_York' - timestamptz '2014-11-02 00:00:00 America/New_York' <= interval '1 day';


-- | timestamp           | boolean |
-- +---------------------+---------+
-- | 2014-11-02 01:00:00 | f       |

So, if you need to test, whether a timestamp/date is within a range, you should manipulate timestampts/dates (or use timestamp/date ranges) & compare those values with <, > or BETWEEN.

SELECT timestamp '2014-11-03 00:00:00' - timestamp '2014-10-03 00:00:00' <= interval '1 mon',
       timestamp '2014-11-03 00:00:00' - interval '1 mon' <= timestamp '2014-10-03 00:00:00';

-- | boolean | boolean |
-- +---------+---------+
-- | f       | t       |