[tz] Fractional seconds in zic input

[John Hawkinson]

I think it is a very serious workflow problem that these potentially destabilizing changes are committed to the tz source tree prior to any discussion.

Indeed, in this case, they were committed on Wed Jan 31 23:13:35 2018 -0800 and then discussion was initiated at Sun, 4 Feb 2018 08:37:52 -0800. And so now the discussion is all about making a case to remove something that's already been committed, rather than a discussion about whether it's appropriate.

I don't think that's a good way for the burden to shift. The burden should be on the proposer of destabilizing changes to justify them; not the other way 'round.


While I don't think that most forward-looking changes need to have discussion and consensus prior to being committed, I tend to think that other kinds of changes probably should.

I realize this is more work for Paul -- a workflow where he can't casually commit to the master branch means keeping track of more stuff. And I'm not trying to suggest there should be a github-oriented "pull request" workflow where each of these changes gets committed on its own branch and only merged to the mainline with consensus or after review. But a lot of projects adopt that kind of workflow (including many that are less likely to cause stability issues throughout the operating system ecosystem) and it is found to be workable.


Personally, I'm on the fence as to whether fractional seconds are destabilizing enough to be excluded. I tend to think they are not going to help and for very little gain. Also, not all downstream consumers are equal.

--jhawk at mit.edu
  John Hawkinson