<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 11 July 2015 at 12:34, Steffen Nurpmeso <span dir="ltr"><<a href="mailto:sdaoden@yandex.com" target="_blank">sdaoden@yandex.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Jon Skeet <<a href="mailto:skeet@pobox.com">skeet@pobox.com</a>> wrote:<br>
|Given how widely used zdump is, we can't really change the format by<br>
|default - but we could perhaps add a new flag to indicate a new format,<br>
|assuming I'm not alone in my objections above?<br>
|(Having said that, a dump with the data in a format I'm not ecstatic about<br>
|would be better for me than no dump at all. I'm certainly not going to<br>
|start chest-thumping about formats.)<br>
<br>
</span>I think Ed Schouten of FreeBSD has done something alike -- based<br>
on zdump(1) that is -- for his CloudABI framework (in FreeBSD and<br>
on that hub). If i understood the presentation he doesn't parse<br>
TZDATA itself but uses the pre-prepared output of zdump(1) to<br>
generate his data; maybe you can simply use that in return.</blockquote><div><br></div><div>Well, as I mentioned before, the zdump data is incomplete - it doesn't show what portion of the total wall offset is due to DST. (So for Antarctica/Troll, for example, there's no way of knowing that the savings are 2 hours.) I haven't looked at the C code implementation yet to see whether that's because zdump chooses not to expose that information, or whether the output of zic doesn't actually include it (in which case zic would presumably need to be cloned or changed).</div><div><br></div><div>Jon</div><div><br></div></div></div></div>