<p dir="ltr">Although that seems reasonable, I think given the new wording in the documentation, most users would expect to find such a transition in the year you call N+1, since that&#39;s when the actual onset of the transition occurs. </p>
<p dir="ltr">--<br>
Tim Parenti<br>
sent from my Android phone</p>
<div class="gmail_quote">On 6 Sep 2014 21:52, &quot;Paul Eggert&quot; &lt;<a href="mailto:eggert@cs.ucla.edu">eggert@cs.ucla.edu</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Tim Parenti wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think there may be an<br>
off-by-one from expected behavior: It includes transition times taking<br>
effect at 01-01 00:00:00Z in the previous year, presumably because the<br>
immediately prior second, included in the output, is 12-31 23:59:59Z.<br>
</blockquote>
<br>
Sorry, I didn&#39;t quite follow that.  The intent is that if there&#39;s a transition between 12-31 23:59:59.999... UTC in year N and 01-01 00:00 UTC in year N+1, the transition is reported in year N.  The other way would work too, as long as it was done consistently, but this way should be a bit easier to compute.<br>
</blockquote></div>