Proposed changing the definition of decade for date_trunc and extract

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

Responses

Browse pgsql-hackers by date

  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)