<div dir="ltr">Next update: I've improved the zdump-based generation of the data, and put the data in the current format for all the tz data releases I can find (from 1996 onwards) at <a href="http://nodatime.org/tzvalidate/">http://nodatime.org/tzvalidate/</a><div><br></div><div>None of this is in any way meant to imply that I'm trying to freeze the format - I appreciate Paul's point about it being an incomplete representation of the zic data - but I wanted to get the data such as it is already out there.</div><div><br></div><div>Noda Time 2.0 alpha now correctly generates the 2012e, 2013e, 2014e and 2015e data - I want to do a bit of work to make it easier to consume the source data as a tgz directly before I then check it against all of the rest of the zdump output files.</div><div><br></div><div>Jon</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 14 July 2015 at 21:12, Jon Skeet <span dir="ltr"><<a href="mailto:skeet@pobox.com" target="_blank">skeet@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><span style="font-size:12.8000001907349px">I've expanded this a bit - we now have implementations for:</span></span><div style="font-size:12.8000001907349px"><ul><li style="margin-left:15px">Joda Time</li><li style="margin-left:15px">Noda Time</li><span class=""><li style="margin-left:15px">Java 7 (well, Java pre-8)</li><li style="margin-left:15px">Java 8</li><li style="margin-left:15px">ICU4J</li><li style="margin-left:15px"><span>zdump</span></li><li style="margin-left:15px">Ruby's tzinfo gem</li></span></ul><span class=""><div>I'd really appreciate any input at this point. There are still a few issues with the data collection - it's not the pristine file diff we'd like to end up with - but it's enough to highlight some discrepancies, which I'll probably write up as a blog post and cc here. I think the fact that it <i>is</i> showing up these differences is evidence that this could provide a lot of value with the support of the rest of the community (and with a better implementation of my <span>zdump</span> munging - ideally something in zic itself, I suspect). Who do I need to persuade? (Paul, I guess...)</div><div><br></div></span><span class="HOEnZb"><font color="#888888"><div>Jon</div><div><br></div></font></span></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 13 July 2015 at 21:43, Jon Skeet <span dir="ltr"><<a href="mailto:skeet@pobox.com" target="_blank">skeet@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Okay, I've created<div><a href="https://github.com/nodatime/tzvalidate" target="_blank">https://github.com/nodatime/tzvalidate</a><br></div><div><br></div><div>It allows you (well, someone who's got everything set up...) to compare and contrast:</div><div><ul><li>Joda Time</li><li>Noda Time</li><li>Java 8</li><li>zdump</li></ul><div>Only Joda Time and Noda Time allow (and in fact require) a data version to be specified. Obviously in order to compare data meaningfully, one has to be using the same data in all places. That's the next thing to look at... but they're all using the same output format, and the results are already interesting in terms of some unexpected discrepanicies. I haven't had a chance to look into them yet.</div></div><span><font color="#888888"><div><br></div><div>Jon</div><div><br></div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 13 July 2015 at 16:06, Jon Skeet <span dir="ltr"><<a href="mailto:skeet@pobox.com" target="_blank">skeet@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Given that I've already found discrepancies (see "Discrepancies in time zone data interpretation") I'm going to go ahead and hack on this in purely pragmatic (read: short term) ways. I'll create a github repo just for this purpose and dump code in there - this is explicitly with the aim of encouraging a more permanent solution by proving value.<div><br></div><div>Will post another message here when there's something worth looking at - I'll be initially looking at zdump output, Joda Time, standard Java, and Noda Time. Contributions from others for other languages/platforms will be very welcome.</div><span><font color="#888888"><div><br></div><div>Jon</div><div><br></div></font></span></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 13 July 2015 at 14:46, Stephen Colebourne <span dir="ltr"><<a href="mailto:scolebourne@joda.org" target="_blank">scolebourne@joda.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">FWIW, I think such a format would be very useful. Effectively, it is a<br>
unit test for others to confirm that they interpret the rules the same<br>
way as intended.<br>
<br>
It is similar to what I produced when trying to demonstrate the amount<br>
of change being caused by apparently "minor" changes to the data:<br>
<a href="https://github.com/jodastephen/tzdiff/commits/master" rel="noreferrer" target="_blank">https://github.com/jodastephen/tzdiff/commits/master</a><br>
<br>
Any output of this type should indeed just consist of a simple text<br>
file with ISO-8601 format timestamps.<br>
<span><font color="#888888"><br>
Stephen<br>
</font></span><div><div><br>
<br>
<br>
On 11 July 2015 at 11:35, Jon Skeet <<a href="mailto:skeet@pobox.com" target="_blank">skeet@pobox.com</a>> wrote:<br>
> Background: I'm the primary developer for Noda Time which consumes the tz<br>
> data. I'm currently refactoring the code to do this... and I've come across<br>
> some code (originally ported from Joda Time) which I now understand in terms<br>
> of what it's doing, but not exactly why.<br>
><br>
> For a little while now, the Noda Time source repo has included a text dump<br>
> file, containing a text dump of every transition (up to 2100, at the moment)<br>
> for every time zone. It looks like this, picking just one example:<br>
><br>
> Zone: Africa/Maseru<br>
> LMT: [StartOfTime, 1892-02-07T22:08:00Z) +01:52 (+00)<br>
> SAST: [1892-02-07T22:08:00Z, 1903-02-28T22:30:00Z) +01:30 (+00)<br>
> SAST: [1903-02-28T22:30:00Z, 1942-09-20T00:00:00Z) +02 (+00)<br>
> SAST: [1942-09-20T00:00:00Z, 1943-03-20T23:00:00Z) +03 (+01)<br>
> SAST: [1943-03-20T23:00:00Z, 1943-09-19T00:00:00Z) +02 (+00)<br>
> SAST: [1943-09-19T00:00:00Z, 1944-03-18T23:00:00Z) +03 (+01)<br>
> SAST: [1944-03-18T23:00:00Z, EndOfTime) +02 (+00)<br>
><br>
> I use this file for confidence when refactoring my time zone handling code -<br>
> if the new code comes up with the same set of transitions as the old code,<br>
> it's probably okay. (This is just one line of defence, of course - there are<br>
> unit tests, though not as many as I'd like.)<br>
><br>
> It strikes me that having a similar file (I'm not wedded to the format, but<br>
> it should have all the same information, one way or another) released<br>
> alongside the main data files would be really handy for all implementors -<br>
> it would be a good way of validating consistency across multiple platforms,<br>
> with the release data being canonical. For any platforms which didn't want<br>
> to actually consume the rules as rules, but just wanted a list of<br>
> transitions, it could even effectively replace their use of the data.<br>
><br>
> One other benefit: diffing the dump between two releases would make it clear<br>
> what had changed in effect, rather than just in terms of rules.<br>
><br>
> One sticking point is size. The current file for Noda Time is about 4MB,<br>
> although it zips down to about 300K. Some thoughts around this:<br>
><br>
> We wouldn't need to distribute it in the same file as the data - just as we<br>
> have data and code file, there could be a "textdump" file or whatever we'd<br>
> want to call it. These could be retroactively generated for previous<br>
> releases, too.<br>
> As you can see, there's redundancy in the format above, in that it's a list<br>
> of "zone intervals" (as I call them in Noda Time) rather than a list of<br>
> transitions - the end of each interval is always the start of the next<br>
> interval.<br>
> For zones which settle into an infinite daylight saving pattern, I currently<br>
> generate from the start of time to 2100 (and then a single zone interval for<br>
> the end of time as Noda Time understands it; we'd need to work out what form<br>
> that would take, if any). If we decided that "year of release + 30 years"<br>
> was enough, that would cut down the size considerably.<br>
><br>
> Any thoughts? If the feeling is broadly positive, the next step would be to<br>
> nail down the text format, then find a willing victim/volunteer to write the<br>
> C code. (You really don't want me writing C...)<br>
><br>
> Jon<br>
><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>