<div dir="ltr"><div dir="ltr">On Wed, Sep 22, 2021 at 3:08 PM Stephen Colebourne <<a href="mailto:scolebourne@joda.org">scolebourne@joda.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The subtlety is in how the data set is consumed. While many downstream<br>
projects use the makefile, not all do. A significant portion of<br>
downstream users make use of the source files directly, with their own<br>
parsers. ie. there is no ability to use a compile-time option. Those<br>
parsers are not setup to use backzone even if it were a valid option<br>
(Tom Lane has indicated how you can't reverse engineer the 2021a data<br>
cleanly from backzone as it is mixed with lots of other historic data<br>
that has been similarly abandoned). Even if the parsers were to be<br>
updated (and in the case of CLDR's backwards compatibiilty it is not<br>
clear that they can), it is not appropriate to have to make the change<br>
without a significant notice period.<br></blockquote><div><br></div><div>I had a feeling this was the answer.</div><div><br></div><div>I think this warrants a critical question: What is the intended interface to the data?  If the intent of the coordinators/maintainers is that consumers will use the compiled version, then one could argue that those consuming the data directly do so at their own risk, because that interface isn't expressly supported.  If so, it would be a layering violation to read the files directly.<br></div><div><br></div><div>But maybe this was never specified, and the interface applications are to use is thus ambiguous (i.e., they have a choice), and it's possibly too far along now to compel them to change.<br></div><div><br></div><div>If the community does choose to undertake a revision of RFC 6557, this might be one of the things that should be reviewed and codified.</div><div><br></div><div>-MSK<br></div></div></div>