Search Postgresql Archives

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thursday, March 30, 2017, Peter J. Holzer <hjp-pgsql@xxxxxx> 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.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux