Pietro Pugni <pietro.pugni@gmail.com> writes:
> Adding 10 years to 1912-02-29 returns 1922-02-29, as expected.
No, it doesn't, and it would be wrong to do so because there is no
such date; 1922 wasn't a leap year.
There are basically three things the addition operator could do here:
throw an error, return 1922-02-28, or return 1922-03-01. The first
choice seems rather unhelpful. The second choice is more in keeping
with what we do for some other similar cases, such as
regression=# select '2017-01-31'::date + '1 month'::interval; ?column?
---------------------2017-02-28 00:00:00
(1 row)
regression=# select '2017-01-31'::date + '3 months'::interval; ?column?
---------------------2017-04-30 00:00:00
(1 row)
Basically the thought is that the last day of the month is more likely
to be the answer the user wants for such cases than the first day of the
next month. If you want the less-fuzzy semantics of, say, "plus 30 days",
you can have that too but you need to say it that way.
The really short answer is that civil calendars were not invented by
mathematicians and expecting them to obey mathematical laws is doomed
to be an exercise in frustration.
> The bug basically consists of the vague meaning of “years” applied to
> leap years. It should be revised in order to be consistent and correct.
As remarked somewhere in our documentation, you'd need to take that up
with the Pope, not with us database hackers. We didn't invent the
calendar rules.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
