Robert Haas <robertmh...@gmail.com> writes:
> On Fri, Jun 19, 2020 at 3:55 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
>> What I'm concerned about is that people depending on the existing
>> behavior are likely to wake up one fine morning and discover that it's
>> broken after a routine tzdata update. I think that it'd be a better
>> user experience for them to see a release-note entry in a PG update
>> release explaining that this will break and here's what to do to fix it.
> I was assuming that if you did an update of the tzdata, you'd notice
> if posixrules had been nuked. I guess that wouldn't help people who
> are using the system tzdata, though.
Yeah, exactly. We can control this easily enough for PG-supplied tzdata
trees, but I think a significant majority of actual users are using
--with-system-tzdata builds, because we've been telling packagers to
do it that way for years. (Nor does changing that advice seem like
a smart move.)
> It might be nice to know what
> Debian, RHEL, etc. plan to do about this, but I'm not sure how
> practical it is to find out.
There's probably no way to know until it happens :-(. We can hope
that they'll be conservative, but it's hard to be sure. It doesn't
help that the bigger players rely on glibc: if I understand what
Eggert was saying, nuking posixrules would bring tzcode's behavior
into closer sync with what glibc does, so they might well feel it's
a desirable change.
regards, tom lane
