A recent thread on -general sparked my interest as I'm working with a large and heterogeneous code base recently converted from Oracle which makes heavy use of TO_DATE() , and it seems this function has a couple of gotchas worthy of consideration.

1. TO_DATE() does not really validate dates.

Even if passed an invalid date, it will happily munge it into a nominally valid date - which is probably not what you want:

# SELECT to_date('2014/02/31', 'YYYY/MM/DD'); to_date ------------ 2014-03-03 (1 row)

A possible workaround is to explicitly cast the string literal to DATE, e.g.:

# SELECT '2014/02/31'::DATE; ERROR: date/time field value out of range: "2014/02/31" LINE 1: SELECT '2014/02/31'::DATE; ^ # SELECT '2014/02/28'::DATE; date ------------ 2014-02-28 (1 row)

but this won't work with as wide a range of date formats as TO_DATE() .

If you really need to parse arbitrary date strings, a function like this might make things safer by converting the output date to the original format, comparing input and output strings and raising an error if the value fails a round-trip:

CREATE OR REPLACE FUNCTION to_date_safe(p_date TEXT, p_format TEXT, OUT r_date DATE) LANGUAGE plpgsql AS $$ BEGIN r_date = TO_DATE(p_date, p_format); IF TO_CHAR(r_date, p_format) != p_date THEN RAISE EXCEPTION 'Input date % does not match output date %', p_date, r_date; END IF; END; $$;

This will mean a slight performance hit, and there might be side-effects I haven't thought about yet, but it seems preferable to silently accepting an incorrect date.

# SELECT to_date_safe('2014/02/31', 'YYYY/MM/DD'); ERROR: Input date 2014/02/31 does not match output date 2014-03-03

2. PostgreSQL's TO_DATE() is not Oracle's TO_DATE()

In Oracle, the DATE datatype is actually equivalent to PostgreSQL's TIMESTAMP(0) - meaning Oracle's TO_DATE() is actually working with timestamps - whereas PostgreSQL's TO_DATE() is working with dates only. Crucially, PostgreSQL's TO_DATE() will ignore any time specifications, meaning the following comparison will not return the result you might be expecting if familiar with the Oracle version:

# SELECT TO_DATE('2014-01-26 10:00:00', 'YYYY-MM-DD HH24:MI:SS') < TO_DATE('2014-01-26 22:00:00', 'YYYY-MM-DD HH24:MI:SS'); ?column? ---------- f

If you are converting TO_DATE() to PostgreSQL, use TO_TIMESTAMP() unless you are comparing calendar dates only. However TO_TIMESTAMP() suffers from the same issue as TO_DATE() .

# SELECT TO_TIMESTAMP('2014-02-31 25:99:00', 'YYYY-MM-DD HH24:MI:SS'); TO_TIMESTAMP ------------------------ 2014-03-04 02:39:00+09 (1 row)

Again, a simple wrapper function doing reverse verification should provide some protection:

CREATE OR REPLACE FUNCTION to_timestamp_safe(p_date TEXT, p_format TEXT, OUT r_date TIMESTAMP) LANGUAGE plpgsql AS $$ BEGIN r_date = TO_TIMESTAMP(p_date, p_format); IF TO_CHAR(r_date, p_format) != p_date THEN RAISE EXCEPTION 'Input date % does not match output date %', p_date, r_date; END IF; END; $$;

Not exhaustively tested but seems to work:

# SELECT to_timestamp_safe('2014/02/31 10:00:00', 'YYYY/MM/DD HH24:MI:SS'); ERROR: Input date 2014/02/31 10:00:00 does not match output date 2014-03-03 10:00:00 # SELECT to_timestamp_safe('2014/02/28 10:00:00', 'YYYY/MM/DD HH24:MI:SS'); to_timestamp_safe --------------------- 2014-02-28 10:00:00 (1 row)

See also this page for some background on why this issue is still around