Re: Re: Proposed changing the definition of decade for date_trunc and extract
От | Gavin Flower |
---|---|
Тема | Re: Re: Proposed changing the definition of decade for date_trunc and extract |
Дата | |
Msg-id | 53DC57DB.5050308@archidevsys.co.nz обсуждение исходный текст |
Ответ на | Re: Proposed changing the definition of decade for date_trunc and extract (David G Johnston <david.g.johnston@gmail.com>) |
Ответы |
Re: Re: Proposed changing the definition of decade for
date_trunc and extract
Re: Re: Proposed changing the definition of decade for date_trunc and extract |
Список | pgsql-hackers |
On 02/08/14 12:32, David G Johnston wrote: > Mike Swanson wrote >> 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...). > Floor ( Year / 10 ) = decade number feels right. Sure, the zero decade only > has 9 years but after that everything is easy to read. Typical usage refers > to decades such as the 80s and the 90s but if you start counting at 1 the 0 > year would have a mis-matched prefix. And date truncation would be > weird...though I haven't tested the behavior I assume it works by basically > just dropping the year digit and replacing it with zero...that at least > would be the desired behavior for me. > > 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. > > David J. > > > > > > > > > -- > View this message in context: http://postgresql.1045698.n5.nabble.com/Proposed-changing-the-definition-of-decade-for-date-trunc-and-extract-tp5813578p5813580.html > Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. > > 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??? :-) Cheers, Gavin
В списке pgsql-hackers по дате отправления: