Re: Proposed changing the definition of decade for date_trunc and extract

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 >
1900.

So -1 to change for breaking backward compatibility and -1 because the
current behavior seems to be more useful in everyday usage.

David J.

--
View this message in context: http://postgresql.1045698.n5.nabble.com/Proposed-changing-the-definition-of-decade-for-date-trunc-and-extract-tp5813578p5813580.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.