On 02/08/14 12:32, David G Johnston wrote:
Since there was no year zero: then it follows that the first decade
comprises years 1 to 10, and the current Millennium started in 2001 - or
am I being too logical??? :-)
Mike Swanson wrote
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...).
Floor ( Year / 10 ) = decade number feels right. Sure, the zero decade only
has 9 years but after that everything is easy to read. Typical usage refers
to decades such as the 80s and the 90s but if you start counting at 1 the 0
year would have a mis-matched prefix. And date truncation would be
weird...though I haven't tested the behavior I assume it works by basically
just dropping the year digit and replacing it with zero...that at least
would be the desired behavior for me.
Any supporting arguments for 1-10 = 1st decade other than technical
perfection? I guess if you use data around and before 1AD you care about
this more, and rightly so, but given sound arguments for both methods the
one more useful to more users who I suspect dominantly care about years >
So -1 to change for breaking backward compatibility and -1 because the
current behavior seems to be more useful in everyday usage.
View this message in context:
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: