Re: [HACKERS] Proposed changing the definition of decade for date_trunc and extract
On Sun, Aug 3, 2014 at 3:29 PM, Gavin Flower wrote: > So it would probably be a good idea to mention in the relevant > documentation, that there was no Year Zero, and that 1 AD follows directly > after 1 BC. Well, maybe. By and large, the PostgreSQL documentation should confine itself to documenting facts about PostgreSQL rather than, say, facts about date reckoning, except to the extent that PostgreSQL does something different from the universal norms. I mean, we could document the rules for leap years, too, or how many days there are in each month, or that many people who used the Julian calendar considered the first day of the year to be March 25th, but really, those are things that mostly deserve to be mentioned in a treatise on historical calendaring rather than our documentation, unless there is some PostgreSQL-specific treatment that requires expounding on them. On the original patch, like a few others who have spoken, I think changing the current behavior is a bad idea. I certainly respect Mike's desire to get the behavior right, and to set things up in the way that makes sense to him, but if we start changing things like this on the basis of a small number of complaints, we will piss off a lot of users. There are many people out there who have thousands upon thousands of lines of PostgreSQL code that they can't easily audit and change, and the standard for doing things that might break that code in subtle ways is, and should be, high. If what we were doing today was outright wrong, of course I'd be in favor of changing it. But the current behavior isn't at all unreasonable; there are two possible definitions and we picked one. In that kind of situation, backward compatibility concerns carry a great deal of weight. Even if, in a vacuum, more users would have chosen to do it as Mike proposes vs. what we actually picked, we'll make enough people unhappy by changing it now to make it a poor decision for the project. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposed changing the definition of decade for date_trunc and extract
On 04/08/14 01:27, Bruce Momjian wrote:
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.
I am not in favour of 'mushroom farming' - keeping people ignorant and
feeding them bullshit. So I don't think we should pander to ignorance.
So it would probably be a good idea to mention in the relevant
documentation, that there was no Year Zero, and that 1 AD follows
directly after 1 BC.
Cheers,
Gavin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposed changing the definition of decade for date_trunc and extract
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 http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposed changing the definition of decade for date_trunc and extract
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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Proposed changing the definition of decade for date_trunc and extract
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...). -- Mike Swanson -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
