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

From: David Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>
Cc: "pgsql-hackers(at)postgresql(dot)org" <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:49:48
Message-ID: CAKFQuwb+=N1BUJ-6fie0quXqcmWNNwHva709ehkd+zCUgb=Quw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Aug 1, 2014 at 8:15 PM, Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>
wrote:

> On 02/08/14 12:32, David G Johnston wrote:
>
>>
>> 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.
>>
>> 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??? :-)
>
>
​This is SQL, only relational logic matters. All other logic can be
superseded by committee consensus.

IOW - and while I have no way of checking - this seems like something that
may be governed by the SQL standard...in which case adherence to that would
trump mathematical logic.

David J.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2014-08-02 03:57:41 Re: B-Tree support function number 3 (strxfrm() optimization)
Previous Message Gavin Flower 2014-08-02 03:15:39 Re: Re: Proposed changing the definition of decade for date_trunc and extract