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

From Bruce Momjian
Subject Re: Proposed changing the definition of decade for date_trunc and extract
Date
Msg-id 20140803132755.GA12284@momjian.us
Whole thread Raw
In response to Re: Proposed changing the definition of decade for date_trunc and extract  (Mike Swanson <mikeonthecomputer@gmail.com>)
Responses Re: Proposed changing the definition of decade for date_trunc and extract
List pgsql-hackers
On Sat, Aug  2, 2014 at 11:53:06PM -0700, Mike Swanson wrote:
> On Fri, 2014-08-01 at 22:28 -0700, Mike Swanson wrote:
> > I'd also argue that the current function basing the logic from
> > definition #2 has limited use even when you want to use it for such.
> > If you want to generate text for '(decades)s' you'd have to do:
> >   SELECT extract('year' from date_trunc('decade', now())) || 's';
> > Or with my patch:
> >   SELECT floor(extract('year' from now()) / 10) || '0s';
> > It's different, for sure, but I would actually think the second one is
> > a bit less awkward.  Plus it's shorter :)
> 
> I'm responding to myself because I realized that what I wrote was a bit
> silly.  The first and current example (which is invalidated by my patch)
> should really be:
>   SELECT extract('decade' from now()) || '0s';
> which makes it the shorter and simpler version of the two.  I'll still
> stand by my opinion that it's not an extremely useful function as it is.

Well, you can make the argument that since the 20th century is from 1901
to 2000, that decades should be from *01 to *00.  However, those
centuries are ordinal, e.g. using "th", while decades are not.  The
decade is more a short-hand, rather than something that counts from year
1 like centuries.  Looking at decades as an abbreviation supports our
current behavior.

I don't think 99% of people know there was no year 0, so I don't think
you can base a lot on that.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: B-Tree support function number 3 (strxfrm() optimization)
Next
From: Emre Hasegeli
Date:
Subject: Re: KNN-GiST with recheck