sql: fix parsing 0000-01-01 11:00:00+00:00 as timestamp

[dbist]

Describe the problem
parsing a time as timestamp will fail on 0000 year. Time field will prepend '0000-01-01' if not defined and parsing will fail.

Please describe the issue you observed, and any steps we can take to reproduce it:

To Reproduce
the following works

          timestamp
+---------------------------+
  0001-01-01 11:00:00+00:00
(1 row)

Time: 356µs

the following will fail

pq: parsing as type timestamp: field year value 0 is out of range

What did you do? Describe in your own words.

If possible, provide steps to reproduce the behavior:

1. start cockroach demo
2. execute the select statements above

Expected behavior
Expect an output similar to:

+---------------------------+
  0000-01-01 11:00:00+00:00
(1 row)

Additional data / screenshots
If the problem is SQL-related, include a copy of the SQL query and the schema
of the supporting tables.

If a node in your cluster encountered a fatal error, supply the contents of the
log directories (at minimum of the affected node(s), but preferably all nodes).

Note that log files can contain confidential information. Please continue
creating this issue, but contact [email protected] to submit the log
files in private.

If applicable, add screenshots to help explain your problem.

Environment:

• CockroachDB version 19.2.1
• Server OS: Darwin Kernel Version 18.7.0: Sat Oct 12 00:02:19 PDT 2019; root:xnu-4903.278.12~1/RELEASE_X86_64 x86_64
• Client app : cockroach demo

Additional context
doing non-distributed export and/or select on time field cast to timestamp will fail.

Add any other context about the problem here.

[yuzefovich]

I think it's a dup of #42749. cc @otan

[otan]

Kind of. Why are they trying to cast it to timestamp instead of time? I have not fixed timestamp because I don't think zero is a valid year, nor is a conversion from time to timestamp.

[otan]

For context, 0000-01-01 a display bug/behaviour in lib/pq (a library we use for formatting). Ideally for lib/pq, time-only displays should not include 0000-01-01 but it does. but even in psql, you can't convert time to timestamp anyway:

otan=# select '10:11:12'::time::timestamp;
ERROR:  cannot cast type time without time zone to timestamp without time zone
LINE 1: select '10:11:12'::time::timestamp;

[otan]

I think this display bug is getting fixed in 20.1, so I'm going to close this one.
see: #21390