Re: inevitability of to_date() when converting representations which don't represent whole timestamps

On Thursday, March 30, 2017, Peter J. Holzer <hjp-pgsql(at)hjp(dot)at> wrote:

> I
> >
> > David tells this is not a bug, but it still seems like a reasonable
> > requirement on to_date() to me. Is there some reason why this isn’t
> > possible?
>
> The documentation warns that to_date “interpret input liberally, with
> minimal error checking” and while it “produce[s] valid output, the
> conversion can yield unexpected results.”
>
> I would agree that producing the same date for every day of the week
> crosses the line between “unexpected (but valid) result” and “bug”.
>
>
What to_date appears to do with the Day specification is throw away the
match just like placeholder text. Left with no other information to
process it then constructs a date - where the day, month, and year are all
missing.

Yes, one could hard-code the word Tuesday to some particular date (absolute
or relative) and deal with the consequent localization issue. But that
isn't in to_dates charter. It doesn't think but simply captures the
necessary date elements from a string into variables and then combines
those values into an actual date. Not all info in the string is useful for
this purpose and so some of it can be discarded.

Maybe the documentation could be improved here but the behavior shown is
not unreasonable.

It would be good to know what Oracel does here since the primary purpose of
to_date is as a compatibility function with that system.

David J.