Why do Postgres timezones change around 1967/68?

Question

On 9.3.3, if one runs:

select EXTRACT(TIMEZONE FROM timestamp with time zone '1911-03-01 00:00 -8:00:00'), EXTRACT(TIMEZONE FROM timestamp with time zone '1911-05-15 00:00 -8:00:00'), EXTRACT(TIMEZONE FROM timestamp with time zone '1917-03-01 00:00 -8:00:00'), EXTRACT(TIMEZONE FROM timestamp with time zone '1917-05-15 00:00 -8:00:00'), EXTRACT(TIMEZONE FROM timestamp with time zone '1967-03-01 00:00 -8:00:00'), EXTRACT(TIMEZONE FROM timestamp with time zone '1967-05-15 00:00 -8:00:00'), EXTRACT(TIMEZONE FROM timestamp with time zone '1968-03-01 00:00 -8:00:00'), EXTRACT(TIMEZONE FROM timestamp with time zone '1968-05-15 00:00 -8:00:00');

One gets the following results:

0;0;
0;3600;
0;3600;
3600;3600

(The first time is the founding day of Las Vegas, the next few are some I used to debug the issue)

It seems there is no offset around 1911, an offset between 1911 and 1967 during summer but not winter and then always has one from 1968 onwards. This seems a little weird. Does anyone have any idea what is going on with the offsets here and whether this is expected behaviour or if there is something in my linux's setup that I could possibly change?

Answer 1

Time zones change for all sorts of reasons.

Daylight savings rules change.

Sometimes timezone offsets change, too, if nations redefine their time zone for political reasons.

The canonical time zone information database is the tz or "zoneinfo" database, which used to be called the Olsen database. The zoneinfo DB is on the IANA site. There are a variety of programs to dump human readable versions of the DB.

You can use timestamp without time zone if you wish to store a particular moment in wall-clock time, without concern for time zone.

timestamp with time zone is sensitive to the system TimeZone setting on input and output, and is stored in UTC time as absolute seconds. So it's converted for input and output. If you want different conversions or to override the conversion you can use the AT TIME ZONE operator.

Answer 2

The rules for your time zone are established by law, and the law changes.

Answer 3

If you want to store the INSTANT at which the (local) clocks in Las Vegas marked 00:00:00 in the day in which the city was founded, and assuming that Las Vegas was using an offset of -8 hours, then you should store 1911-03-01 00:00 -8:00:00::timezonetx in a timezonetx field. Be aware, however, that what is really stored is only the "universal instant", when you read it you cannot know to which "local time at Las Vegas" it corresponds (unless you explicityl convert it, after reading it, to a timezone).

Answer 4

Depends on your timezone, really. In 1966, DST was first implemented nationally in the US to take place in 1967. States needed to pass laws to end it, meaning that in many areas, 1967 is the only year which used DST. This can lead to some very interesting glitches, where every date except those in 1967/68 behaves normally.