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

From: Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>
To: David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: Proposed changing the definition of decade for date_trunc and extract
Date: 2014-08-02 03:15:39
Message-ID: 53DC57DB.5050308@archidevsys.co.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Johnston 2014-08-02 03:49:48 Re: Re: Proposed changing the definition of decade for date_trunc and extract
Previous Message Josh Berkus 2014-08-02 01:25:44 Re: Re: Proposed changing the definition of decade for date_trunc and extract