Re: BUG #16419: wrong parsing BC year in to_date() function

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #16419: wrong parsing BC year in to_date() function
Date: 2020-10-01 00:40:58
Message-ID: 946889.1601512858@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Right. Ultimately, this comes down to a judgement call about what you
> think people are likely to rely on, and what you think they are
> unlikely to rely on.

Good, so at least we agree on that principle.

> But the present case does not seem to me to be comparable. If someone
> is using to_date() to construct date values, I can't see why they
> wouldn't test it, find out how it works with BC values, and then make
> the application that generates the input to that function do the right
> thing for the actual behavior of the function. There are discussions
> of the behavior of to_date with YYYY = 0 going back at least 10 years
> on this mailing list, and more recent discussions of the behavior of
> negative numbers.

Sure, we have at least two bug reports proving that people have
investigated this. What I'm saying is unlikely is that there are any
production applications in which it matters. I doubt that, say, the
Italian government has a citizenry database in which they've recorded
Julius Caesar's birthday; and even if they do, they're probably not
squirting the data through to_date; and even if they are, they're more
likely using the positive-year-with-BC representation, because that's
the only one that PG will emit. Even if they've got code that somehow
relies on to_date working this way, it's almost certainly getting zero
use in practice.

I probably wouldn't have taken an interest in this at all, were it
not for the proposal that we document the misbehavior. Doing that
rather than fixing it just seems silly.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message ChandraKumar Ovanan 2020-10-01 06:23:52 Re: BUG #16636: Upper case issue in JSONB type
Previous Message David G. Johnston 2020-10-01 00:38:05 Re: BUG #16419: wrong parsing BC year in to_date() function

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2020-10-01 01:01:56 Re: Disable WAL logging to speed up data loading
Previous Message David G. Johnston 2020-10-01 00:38:05 Re: BUG #16419: wrong parsing BC year in to_date() function