From: | Mike Swanson <mikeonthecomputer(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Proposed changing the definition of decade for date_trunc and extract |
Date: | 2014-08-02 00:02:58 |
Message-ID: | 1406937778.11508.1.camel@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
For a long time (since version 8.0), PostgreSQL has adopted the logical
barriers for centuries and millenniums in these functions. The calendar
starts millennium and century 1 on year 1, directly after 1 BC.
Unfortunately decades are still reported rather simplistically by
dividing the year by 10. Years 1-10 are logically the first decade and
working up from there, year 2014 should be counted as 202nd decade.
I've pushed code and documentation changes to reflect this, based on the
master branch (9.5devel), it's on the branch new_decade_def at
https://github.com/chungy/postgres.git -- In both the commit message and
docs, I made note of the backwards compatibility change. I don't know
how much of an impact this would have but I suspect not many
applications are really going to be affected by how decades are counted
(should be simple to fix on their part, if any are...).
-- Mike Swanson
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2014-08-02 00:30:56 | Small patch to fix windows build |
Previous Message | Peter Geoghegan | 2014-08-01 23:00:11 | Re: B-Tree support function number 3 (strxfrm() optimization) |