| 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: | Whole Thread | Raw Message | 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 |