=?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.org> writes:
> I have a bunch of servers that never restarted in the past couple of months
> and had postgres running since before Nov. 4th and I discovered that their
> default timezone changed in the background.
Hmph. Ordinarily I'd expect that the default zone data would be cached
in the postmaster and inherited via fork() by backends, so that as long
as you didn't do something like change the timezone setting in
postgresql.conf, the behavior would be stable until postmaster restart.
(People who live in zones with frequent DST law changes have complained
of that ... but I'm not very much in a hurry to change it.)
So it's not at all clear what happened here. I think that Red Hat did
push out a tzdata update in early November, but even so, the behavior
of America/Los_Angeles shouldn't have changed. *Maybe* this could
be explained by having restarted those postmasters during the tiny
interval where the package update was happening and there wasn't anything
valid for /etc/localtime to point at --- but that stretches credulity.
If you can figure out a way to reproduce this, we'd be interested to
hear what it is.
regards, tom lane
