<div dir="ltr">(Snipped.)<br><div class="gmail_extra"><br><div class="gmail_quote">On 21 August 2016 at 11:42, Paul Eggert <span dir="ltr">&lt;<a href="mailto:eggert@cs.ucla.edu" target="_blank">eggert@cs.ucla.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">and &quot;d&quot; instead of &quot;a positive<br>
integer&quot; to indicate daylight. (My goal is for this to capture all the<br>
relevant information from the original data text files, but the<br>
implementation details of is_dst fall outside that scope IMO. That&#39;s not<br>
part of the source data.)<br>
</blockquote>
<br></span>
The decimal integer does both, no? That is, it captures all the relevant information from the original data text files, and it also captures the POSIX-specified implementation details. Since zdump is supposed to be portable to other implementations where the value of the flag may matter, I&#39;m still inclined to have the -i format output that information, as the -v format already does.</blockquote><div><br></div><div>The problem is it isn&#39;t canonical at that point - from the perspective of information in the source text. If two valid implementations can give two different outputs, that&#39;s a problem for my use case. More below.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I&#39;m still fine with the idea of transforming some non-ideal-to-me format<br>
from zdump into a more canonical format in a simple way though.<br>
</blockquote>
<br></span>
I plan to tweak the -i format to add colons to UT offsets, and do a couple of other things to make it easier to view and process (notably, use tabs rather than spaces to separate fields, so that people who want columns to line up can easily do that).<br></blockquote><div><br></div><div>Well, if the output format isn&#39;t suitable as a canonical format for validating tz text consumers, the readability doesn&#39;t matter as much to me... so long as I can convert it into a format I&#39;m happier with. The question is really whether we want there to be two formats for the two slightly different use cases or not.</div><div>Now the part about using an unspecified integer or not could be argued to be more theoretical than practical, of course... if the output data in the release will always use 1 and 0, I guess I could canonicalize to that... it doesn&#39;t feel nice in terms of relying on anything unspecified, but it may still be better than having two different formats.</div><div><br></div><div>(I&#39;m personally not a big fan of tabs, but I don&#39;t want to waste everyone&#39;s time by arguing forever...)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, I would like to distribute a new file that contains the zdump -i output, so that changes to the tzdata source can easily be tracked by diffing the zdump -i output. This should help with regression testing.<br></blockquote><div><br></div><div>Yes, that would definitely be helpful, regardless of whether the format is precisely what I&#39;d like :)</div><div><br></div><div>Jon</div><div><br></div></div></div></div>