cockroachdb / cockroachdb/cockroach

sql: timezone abbreviations should not consider daylight savings

Open
#94,078 5 comments 0 reactions 0 assignees View on GitHub
A-sql-semantics C-bug
Dominant language
Go
Stars
32.5k
Forks
4.1k
PR merge metrics
PR metrics pending

Description

**Root cause**

See https://github.com/cockroachdb/cockroach/issues/94078#issuecomment-1363286516

Timezone abbreviations (e.g. CET, EST) in CockroachDB should not consider daylight savings. It currently does.

We should make abbreviations map to exact timezones which do not consider daylight savings (we should make `LoadLocation` use `time.FixedOffsetToLocation`) and have this correspond to this table: the accurate mapping is in Table B-4 in https://www.postgresql.org/docs/8.1/datetime-keywords.html (or use the pg_timezone_abbrevs table). Note the table changes based on a session variable!

----

**Describe the problem**
If you specify a session timezone variable value of "CET" (Central European Time) -- which is +0100 from UTC, you get some unexpected results in CRDB.

**To Reproduce**

```
root@localhost:26257/defaultdb> show time zone;
timezone
------------
UTC
(1 row)
Time: 1ms total (execution 0ms / network 0ms)
root@localhost:26257/defaultdb> select '2022-10-01 00:00:00.000 +0100'::timestamptz;
timestamptz
--------------------------
2022-09-30 23:00:00+00
(1 row)
Time: 1ms total (execution 0ms / network 0ms)
root@localhost:26257/defaultdb> set timezone = CET;
SET
Time: 1ms total (execution 0ms / network 0ms)
root@localhost:26257/defaultdb> select '2022-10-01 00:00:00.000 +0100'::timestamptz;
timestamptz
--------------------------
2022-10-01 01:00:00+02
(1 row)
Time: 1ms total (execution 0ms / network 0ms)
```

**Expected behavior**
CRDB should interpret the value as '+01' and not '+02' in the example above.

You *do* see this +01 behavior if you select now()
```
root@localhost:26257/defaultdb> show time zone; timezone
------------
UTC
(1 row)
Time: 1ms total (execution 0ms / network 0ms)
root@localhost:26257/defaultdb> select now(); now
---------------------------------
2022-12-21 12:19:54.391332+00
(1 row)
Time: 1ms total (execution 1ms / network 0ms)
root@localhost:26257/defaultdb> set timezone = CET; SET
Time: 1ms total (execution 1ms / network 0ms)
root@localhost:26257/defaultdb> select now(); now
---------------------------------
2022-12-21 13:19:58.485478+01
(1 row)
Time: 1ms total (execution 1ms / network 0ms)
```

You can take this a step further and convert the values back to timezone and you get values that are 2 hours apart but should only be 1 hour apart; if you run this test in PG, you get values that are 1 hour apart.
```
root@localhost:26257/test> select timezone('CET', '2022-10-01 00:00:00.000 +0100'::timestamptz);
timezone
-----------------------
2022-10-01 01:00:00
(1 row)

Time: 1ms total (execution 0ms / network 0ms)

root@localhost:26257/test> select timezone('UTC', '2022-10-01 00:00:00.000 +0100'::timestamptz);
timezone
-----------------------
2022-09-30 23:00:00
(1 row)
```

**Additional data / screenshots**
I suspect part of the issue here is the code being used (i.e., CET). If you specify the timezone as: `set timezone = '+01:00';`, then it works correctly.

I opened a separate docs ticket to provide a list of acceptable time zone codes which I think could be helpful in avoiding confusion on this type of issue: https://github.com/cockroachdb/docs/issues/15873

**Environment:**
root@localhost:26257/test> select version();
version
-------------------------------------------------------------------------------------------
CockroachDB CCL v22.2.0 (aarch64-apple-darwin21.2, built 2022/12/05 16:56:56, go1.19.1)
(1 row)

Jira issue: CRDB-22682

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.