CLDR is set up to work with any stock version of the tzdb of a given version or later. While we could make an internal change in a tzdb used for testing with CLDR, it means we would be out of sync with whatever tzdb was being used with it by others. If the tzdb doesn't change, some things will just not work properly, which is why we were hoping that it wouldn't be too much trouble to get a new standard version of the tzdb. It is understandable if there are production constraints that prevent this.
<br><br>Mark<br><br><div class="gmail_quote">On Nov 13, 2007 9:31 AM, Paul Eggert <<a href="mailto:eggert@cs.ucla.edu">eggert@cs.ucla.edu</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">"Mark Davis" <<a href="mailto:mark.davis@icu-project.org">mark.davis@icu-project.org</a>> writes:<br><br></div><div class="Ih2E3d">> now we are missing a mapping from<br>> country codes to timezone for the new country codes.
<br><br></div>Can you map the new country codes to America/Guadeloupe for now?<br>That will be equivalent to anything we do in tz.<br><br></blockquote></div><br><br clear="all"><br>-- <br>Mark