Given the long lead time for deployment of TZ data in some cases, may I suggest that we expedite the release of the changes for Russia in 2014f, and defer any contentious changes to a subsequent release? Thank you, Deborah
Deborah Goldsmith wrote:
may I suggest that we expedite the release of the changes for Russia in 2014f, and defer any contentious changes to a subsequent release?
We could release just the Russia changes, but I think it'd be better to hash out differences one way or another on the relatively minor issues that have seen so much email recently, so that downstream users can do proper integration testing as mentioned by Andy Heninger a couple of weeks ago. This shouldn't take too long (I'm thinking days rather than weeks) and should give a reasonable amount of lead time for the late-October Russia changes.
On 31/07/14 22:47, Paul Eggert wrote:
Deborah Goldsmith wrote:
may I suggest that we expedite the release of the changes for Russia in 2014f, and defer any contentious changes to a subsequent release?
We could release just the Russia changes, but I think it'd be better to hash out differences one way or another on the relatively minor issues that have seen so much email recently, so that downstream users can do proper integration testing as mentioned by Andy Heninger a couple of weeks ago. This shouldn't take too long (I'm thinking days rather than weeks) and should give a reasonable amount of lead time for the late-October Russia changes. I'm one of those relatively long lead time consumers :) In my case it would be highly beneficial to have an 2014f release with only the October Russia changes .
Seen, besides these RU changes , there are no future DST changes pending would it not be a good idea to release 2014f with these RU changes only (compared to 2014e) and then release an 2014g that has the other changes? that way the updated RU rules can be directly consumed and then testing can be done without any immediate "pressure". I can brew my own "2014f with these RU changes only (compared to 2014e)" but i prefer to follow the standard IANA releases to avoid confusion . Gunther
I would like to support Gunther’s suggestion of releasing 2014f with solely the changes for Russia, and resolving the discussion of other changes in 2014g. Deborah
On Aug 4, 2014, at 4:48 PM, gunther Vermeir <gunther.vermeir@gmail.com> wrote:
On 31/07/14 22:47, Paul Eggert wrote:
Deborah Goldsmith wrote:
may I suggest that we expedite the release of the changes for Russia in 2014f, and defer any contentious changes to a subsequent release?
We could release just the Russia changes, but I think it'd be better to hash out differences one way or another on the relatively minor issues that have seen so much email recently, so that downstream users can do proper integration testing as mentioned by Andy Heninger a couple of weeks ago. This shouldn't take too long (I'm thinking days rather than weeks) and should give a reasonable amount of lead time for the late-October Russia changes. I'm one of those relatively long lead time consumers :) In my case it would be highly beneficial to have an 2014f release with only the October Russia changes .
Seen, besides these RU changes , there are no future DST changes pending would it not be a good idea to release 2014f with these RU changes only (compared to 2014e) and then release an 2014g that has the other changes?
that way the updated RU rules can be directly consumed and then testing can be done without any immediate "pressure".
I can brew my own "2014f with these RU changes only (compared to 2014e)" but i prefer to follow the standard IANA releases to avoid confusion .
Gunther
On 05/08/14 15:29, Deborah Goldsmith wrote:
I would like to support Gunther’s suggestion of releasing 2014f with solely the changes for Russia, and resolving the discussion of other changes in 2014g.
I'd second that. While I understand the principle behind the historic changes, the justification still does not hold up. We know that some areas need formal authentication, But changing something just because it MAY be wrong is what is objected to. If it is proven wrong because there is a proven correct version then OK, but switching one unproven fact with another ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Lester Caine wrote:
If it is proven wrong because there is a proven correct version then OK, but switching one unproven fact with another ...
Those changes mostly remove dubious data, rather than replacing one dubious datum with another. In a few places dubious data were replaced with less-dubious data, but these exceptions were individually justified with sources. In the long run it'd be better to remove dubious data, or at least move it to a "dubious" area optionally available to users who prefer it; but one step at a time.
On 06/08/14 19:32, Paul Eggert wrote:
If it is proven wrong because there is a proven correct version then OK, but switching one unproven fact with another ...
Those changes mostly remove dubious data, rather than replacing one dubious datum with another. In a few places dubious data were replaced with less-dubious data, but these exceptions were individually justified with sources.
In the long run it'd be better to remove dubious data, or at least move it to a "dubious" area optionally available to users who prefer it; but one step at a time.
If the removing of dubious data results in the answers generated changing then that is the stability that is objected to. These changes resulting new output that is only changing because of two lots of dubious states is the problem. Documenting that to the consumer is difficult bit here when you are saying it's changed because we don't know what it should be ... yes the previous answer is dubious, but so is the reason for changing it? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
At this point let's just ship what we have, Russia included. Although there's never a perfect time to ship non-urgent changes, now's as good a time as any, and if there are any significant problems we can simply issue 2014g to fix them. I've tagged 2014f in the experimental version; please expect an official announcement soon.
participants (4)
-
Deborah Goldsmith -
gunther Vermeir -
Lester Caine -
Paul Eggert