Re: [PATH] Correct negative/zero year in to_date/to_timestamp - Mailing list pgsql-hackers
From | Vitaly Burovoy |
---|---|
Subject | Re: [PATH] Correct negative/zero year in to_date/to_timestamp |
Date | |
Msg-id | CAKOSWNnHiP-LgJ=v-p7YtaA=tF5gKWxFf4SWsUvycAA00SFnfQ@mail.gmail.com Whole thread Raw |
In response to | Re: [PATH] Correct negative/zero year in to_date/to_timestamp (Robert Haas <robertmhaas@gmail.com>) |
Responses |
Re: [PATH] Correct negative/zero year in to_date/to_timestamp
|
List | pgsql-hackers |
On 2/27/16, Robert Haas <robertmhaas@gmail.com> wrote: > On Tue, Feb 23, 2016 at 6:23 AM, Thomas Munro > <thomas.munro@enterprisedb.com> wrote: >> This seems to be a messy topic. The usage of "AD" and "BC" imply that >> TO_DATE is using the anno domini system which doesn't have a year 0, >> but in the DATE type perhaps we are using the ISO 8601 model[2] where >> 1 BC is represented as 0000, leading to the difference of one in all >> years before 1 AD? > > Well, the way to figure that out, I think, is to look at the > documentation. I had a look at... > > http://www.postgresql.org/docs/9.5/static/functions-formatting.html > > ...which says... > > YYYY year (4 or more digits) > IYYY ISO 8601 week-numbering year (4 or more digits) > > I don't really understand ISO 8601, but if IYYY is giving us an ISO > 8601 thing, then presumably YYYY is not supposed to be giving us that. > The same page elsewhere refers to Gregorian dates, and other parts > of the documentation seem to agree that's what we use. > > But having said that, this is kind of a weird situation. We're > talking about this: > > rhaas=# SELECT y || '-06-01', to_date (y || '-06-01', 'YYYY-MM-DD') > FROM (VALUES (2), (1), (0), (-1), (-2)) t(y); > ?column? | to_date > ----------+--------------- > 2-06-01 | 0002-06-01 > 1-06-01 | 0001-06-01 > 0-06-01 | 0001-06-01 BC > -1-06-01 | 0002-06-01 BC > -2-06-01 | 0003-06-01 BC > (5 rows) > > Now, I would be tempted to argue that passing to_date('-1-06-01', > 'YYYY-MM-DD') ought to do the same thing as to_date('pickle', > 'YYYY-MM-DD') i.e. throw an error. There's all kinds of what seems to > me to be shoddy error checking in this area: > > rhaas=# select to_date('-3', 'YYYY:MM&DD'); > to_date > --------------- > 0004-01-01 BC > (1 row) > > It's pretty hard for me to swallow the argument that the input matches > the provided format. > > However, I'm not sure we ought to tinker with the behavior in this > area. If YYYY-MM-DD is going to accept things that are not of the > format YYYY-MM-DD, and I'd argue that -1-06-01 is not in that format, It is not about format, it is about values. > then I think it should probably keep doing the same things it's always > done. If you want to supply a BC date, why not do Because it is inconvenient a little. If one value ("-2345") is passed, another one ("2346 BC") is got. In the other case a programmer must check for negative value, and if so change a sign and add "BC" to the format. Moreover the programmer must keep in mind that it is not enough to have usual date format "DD/MM/YYYY", because sometimes there can be "BC" part. > this: > > rhaas=# select to_date('0001-06-01 BC', 'YYYY-MM-DD BC'); > to_date > --------------- > 0001-06-01 BC > (1 row) Also because of: postgres=# SELECT EXTRACT(year FROM to_date('-3', 'YYYY'));date_part ----------- -4 (1 row) Note that the documentation[1] says "Keep in mind there is no 0 AD". More examples by the link[2]. > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company [1]http://www.postgresql.org/docs/devel/static/functions-datetime.html [2]http://www.postgresql.org/message-id/CAKOSWNn6KpfAbmrsHzyN8+2NHpyfVBdMPHYa5pQgUNy8LP2L2Q@mail.gmail.com -- Best regards, Vitaly Burovoy
pgsql-hackers by date: