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