sql: timezones after 2038 use incorrect DST settings

[otan]

Cockroach stops propagating DST after 2037:

[email protected]:57882/defaultdb> SET TIME ZONE 'America/Chicago';

[email protected]:57882/defaultdb> select '2038-09-06 04:15:30.746999-06:00'::timestamptz;
            timestamptz
------------------------------------
  2038-09-06 04:15:30.746999-06:00
(1 row)

Time: 321µs

[email protected]:57882/defaultdb> select '2037-09-06 04:15:30.746999-06:00'::timestamptz;
            timestamptz
------------------------------------
  2037-09-06 05:15:30.746999-05:00
(1 row)

Time: 399µs

Compared to postgres:

otan=# set time zone 'America/Chicago';
SET
otan=# select '2038-09-06 04:15:30.746999-06:00'::timestamptz;
          timestamptz
-------------------------------
 2038-09-06 05:15:30.746999-05
(1 row)

otan=#  select '2037-09-06 04:15:30.746999-06:00'::timestamptz;
          timestamptz
-------------------------------
 2037-09-06 05:15:30.746999-05
(1 row)

This is actually not resolvable after #36864 since it is the parsing of golang's time data does not consider "extended" information, and in order to use In, we have to give a time.Location which is a private struct which can only be made internally in the time.Location package.

This will be addressed in Golang by golang/go#36654, but requires a cockroach golang upgrade after the fix for this issue is merged in.

Jira issue: CRDB-5185

[otan]

looks like go has submitted a fix in -- now it's a matter of that patch being available in the next Go version we use.

[otan]

upgraded go version!