Re: More tzdb fun: POSIXRULES is being deprecated upstream

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: More tzdb fun: POSIXRULES is being deprecated upstream
Дата
Msg-id 2269044.1593094380@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: More tzdb fun: POSIXRULES is being deprecated upstream  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: More tzdb fun: POSIXRULES is being deprecated upstream  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> What you are saying is, instead of the OS dropping POSIXRULES support, 
> it would be better if we dropped it first and release-noted that. 
> However, I don't agree with the premise of that.  OSes with long-term 
> support aren't going to drop it.

You might be right, or you might not.  I think the tzdata distribution is
in a weird gray area so far as long-term-support platforms are concerned:
they have to keep updating it, no matter how far it diverges from what
they originally shipped with.  Maybe they will figure out that they're not
required to drop POSIXRULES just because upstream did.  Or maybe they will
go with the flow on that, figuring that it's not any worse than any
politically-driven time zone change.

I wouldn't be a bit surprised if it ends up depending on whether the
particular distro is using IANA's makefile more or less verbatim.
In Red Hat's case I found that they'd have to take positive action to
drop POSIXRULES, so I'd agree that it won't happen there for a long time,
and not in any existing RHEL release.  In some other distros, it might
take explicit addition of a patch to keep from dropping POSIXRULES, in
which case I think there'd be quite good odds that that won't happen
and the changeover occurs with the next IANA zone updates.

The nasty thing about that scenario from our perspective is that it
means that the same timezone spec means different things on different
platforms, even ones nominally using the same tzdata release.  Do we
want to deal with that, or take pre-emptive action to prevent it?

(You could argue that that hazard already exists for people who are
intentionally using nonstandard posixrules files.  But I think the
set of such people can be counted without running out of fingers.
If there's some evidence to the contrary I'd like to see it.)

I'm also worried about what the endgame looks like.  It seems clear
that at some point IANA is going to remove their code's support for
reading a posixrules file.  Eggert hasn't tipped his hand as to when
he thinks that might happen, but I wouldn't care to bet that it's
more than five years away.  I don't want to find ourselves in a
situation where we have to maintain code that upstream has nuked.
If they only do something comparable to the patch I posted, it
wouldn't be so bad; but if they then undertake any significant
follow-on cleanup we'd be in a very bad place for tracking them.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: Why forbid "INSERT INTO t () VALUES ();"
Следующее
От: Daniel Gustafsson
Дата:
Сообщение: Re: improving basebackup.c's file-reading code