I observed this issue while serializing/deserializing timestamps in test cases. The serialized strings from the database had a mismatch at UTC/UCT, and a lot of sensitive test cases broke due to this, and took us two days to realize that maybe the postgres docker image was at fault (our local installations were working fine!)
Thanks for pointing out that the /etc/timezone was playing a part - all the computers I had tested with did have `/etc/timezone` set as Etc/UTC. I know that UCT is just an alias of UTC, just like Etc/UTC. It is an issue because I think UCT should not be promoted as a default for any reason in any place. On Tue, 4 Jun 2019 at 14:03, Christoph Berg <m...@debian.org> wrote: > Control: found -1 11.3-1 > > Re: Kumar Harsh 2019-06-04 <CAM8Q7gMxYQ+dh= > z_dyqhyazyfaiskqsijaocfcyn3yvlghz...@mail.gmail.com> > > Package: postgresql-11 > > Version: 11.3.1 > > > > The postgres system has the default timezone set to 'UCT' > > instead of 'UTC'. This bug was introduced in version 9.6.12, > > and hasn't been fixed as of the latest stable version (11.3.1). > > Fwiw, the "default" timezone is whatever your system uses in > /etc/timezone, so your "reproducible" example is only half-working. > > But there's indeed a problem, if /etc/timezone is Etc/UTC, initdb sets > timezone = UCT. > > OTOH I wonder why that's even an issue, the effective timezone +00 is > just the same? (And that's what's used in timestamp input/output, not > the timezone name.) > > Christoph >
