Seems like I'm not getting any traction in convincing people that
back-patching this change is wise. To get this closed out before
the CF starts, I'm just going to put it into HEAD/v13 and call it
a day.
I remain of the opinion that we'll probably regret not doing
anything in the back branches, s
Peter Eisentraut 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, o
On 2020-06-19 21:55, Tom Lane wrote:
Yeah, we can do nothing in the back branches and hope that that doesn't
happen for the remaining lifespan of v12. But I wonder whether that
doesn't amount to sticking our heads in the sand.
I suppose it'd be possible to have a release-note entry in the back
Robert Haas writes:
> 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.
By luck, we now have a moderately well-educated guess about that
from Paul Eggert himself [1]:
: Probably NetBSD will go first as they tend to buy t
I wrote:
> Robert Haas writes:
>> 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 :-(.
On the other hand, for the open-source players, it might be easier to
guess.
Robert Haas writes:
> On Fri, Jun 19, 2020 at 3:55 PM Tom Lane 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 expe
On Fri, Jun 19, 2020 at 3:55 PM Tom Lane wrote:
> The code delta is small enough that I don't foresee any real maintenance
> problem if we let the back branches differ from HEAD/v13 on this point.
> What I'm concerned about is that people depending on the existing
> behavior are likely to wake up
Robert Haas writes:
> It's really unclear to me why we should back-patch this into
> already-released branches. I grant your point that perhaps few people
> will notice, and also that this might happen at some point the change
> will be forced upon us. Nonetheless, we bill our back-branches as
> b
On Fri, Jun 19, 2020 at 3:27 PM Tom Lane wrote:
> Anyway, as I write this I'm kind of talking myself into the position
> that we should indeed back-patch this. The apparent stability
> benefits of not doing so may be illusory, and if we back-patch then
> at least we get to document that there's a
Peter Eisentraut writes:
> On 2020-06-17 20:08, Tom Lane wrote:
>> I would definitely be in favor of "nuke it now" with respect to HEAD.
>> It's a bit more debatable for the back branches. However, all branches
>> are going to be equally exposed to updated system tzdata trees, so
>> we've typical
I wrote:
> I experimented with removing the posixrules support, and was quite glad
> I did, because guess what: our regression tests fall over. If we do
> nothing we can expect that they'll start failing on various random systems
> come this fall.
To clarify, you can produce this failure without
On 2020-06-17 20:08, Tom Lane wrote:
I would definitely be in favor of "nuke it now" with respect to HEAD.
It's a bit more debatable for the back branches. However, all branches
are going to be equally exposed to updated system tzdata trees, so
we've typically felt that changes in the tz-related
I wrote:
> ... We should expect that, starting probably this fall, there
> will be installations with no posixrules file.
> The minimum thing that we have to do, I'd say, is to change the
> documentation to explain what happens if there's no posixrules file.
> However, in view of the fact that the
Robert Haas writes:
> You could consider something along the lines of:
> This form specifies a transition that always happens during the same
> month and on the same day of the week. m identifies the month, from 1
> to 12. n specifies the n'th occurrence of the day number identified by
> d. n is
On Thu, Jun 18, 2020 at 1:05 PM Tom Lane wrote:
> Robert Haas writes:
> > It's a little confusing, though, that you documented it as Mm.n.d but
> > then in the text the order of explanation is d then m then n. Maybe
> > switch the text around so the order matches, or even use something
> > like M
Robert Haas writes:
> It's a little confusing, though, that you documented it as Mm.n.d but
> then in the text the order of explanation is d then m then n. Maybe
> switch the text around so the order matches, or even use something
> like Mmonth.occurrence.day.
Yeah, I struggled with that text for
On Thu, Jun 18, 2020 at 12:26 AM Tom Lane wrote:
> Here's a proposed patch to do that. To explain this, we more or less
> have to fully document the POSIX timezone string format (otherwise
> nobody's gonna understand what "M3.2.0,M11.1.0" means). That's something
> we've glossed over for many ye
I wrote:
> The minimum thing that we have to do, I'd say, is to change the
> documentation to explain what happens if there's no posixrules file.
Here's a proposed patch to do that. To explain this, we more or less
have to fully document the POSIX timezone string format (otherwise
nobody's gonna
Last year I wrote:
> Paul Eggert, in https://mm.icann.org/pipermail/tz/2019-June/028172.html:
>> zic’s -p option was intended as a transition from historical
>> System V code that treated TZ="XXXnYYY" as meaning US
>> daylight-saving rules in a time zone n hours west of UT,
>> with XXX abbreviating
Paul Eggert, in https://mm.icann.org/pipermail/tz/2019-June/028172.html:
> zic’s -p option was intended as a transition from historical
> System V code that treated TZ="XXXnYYY" as meaning US
> daylight-saving rules in a time zone n hours west of UT,
> with XXX abbreviating standard time and YYY ab
20 matches
Mail list logo
