[tz] Fractional seconds in zic input

[John Hawkinson]

Paul Eggert <eggert at cs.ucla.edu> wrote on Mon,  5 Feb 2018
at 09:51:01 -0800 in <b4466354-1e55-f0ce-c318-da3be94f2a34 at cs.ucla.edu>:

> The changes were not published on GitHub until the weekend (the
> exact timestamp of isn't maintained on GitHub as far as I know).

Sorry, yes. They were pushed to github sometime before Sat, 03 Feb 2018 21:00:04 -0000 (which is when I got notice, via RSS at 20 min. granularity). Err, that's Sat Feb  3 13:00:04 PST 2018 for comparison with the thread discussion time: Sun, 4 Feb 2018 08:37:52 -0800.

> The Wednesday timestamp is that of a patch I prepared on Wednesday
> but did not push to GitHub until this weekend. (At times I pause
> work on tzdb and work on something else and one of those times was
> Wednesday through the weekend.) I initiated discussion on the topic
> at the moment I noticed the changes hitting GitHub.

A case could be made that both of these are things that matter.

That is, one of the strongest reasons to favor discussion-before-committing is to avoid having the community have argue to remove something that you (Paul) have worked hard on, and therefore is a sunk cost for you. It is unpleasant to argue to someone that their past work is wasted, and especially hard to argue when you put in so much time dedicated to the project. So from that perspective, that amount of time from when the changes were implemented to when discussion started (e.g. time to bake in your head and grow comfortable with them) is pertinent.

But on the other hand, sure, we all work on stuff and refactor it (especially in the world of git and other DVCSs) and the timestamps can reflect the time work was started (perhaps abortively) rather than completed, and so can be somewhat meaningless, so maybe we should just look at when they are published to the world for discussion.


In any case, my chief concern isn't the amount of time. It's the burden of persuasion or the presumption of release.

I'd say that any tzcode change is a potentially destabilizing change, and future changes to tzdata are generally not potentially destabilizing, and past changes to tzdata are potentially destabilizing. I'm not sure that's the right framework though, but it is what comes to mind.

--jhawk at mit.edu
  John Hawkinson