Re: Re: Proposed changing the definition of decade for date_trunc and extract - Mailing list pgsql-hackers

From Gavin Flower
Subject Re: Re: Proposed changing the definition of decade for date_trunc and extract
Date
Msg-id 53DC57DB.5050308@archidevsys.co.nz
Whole thread Raw
In response to Re: Proposed changing the definition of decade for date_trunc and extract  (David G Johnston <david.g.johnston@gmail.com>)
Responses Re: Re: Proposed changing the definition of decade for date_trunc and extract
Re: Re: Proposed changing the definition of decade for date_trunc and extract
List pgsql-hackers
On 02/08/14 12:32, David G Johnston wrote:
> 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.
>
>
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???   :-)


Cheers,
Gavin



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Re: Proposed changing the definition of decade for date_trunc and extract
Next
From: David Johnston
Date:
Subject: Re: Re: Proposed changing the definition of decade for date_trunc and extract