<br><div class="gmail_quote">On Sun, Sep 30, 2012 at 8:33 AM, Benjamin Peterson <span dir="ltr"><<a href="mailto:benjamin@python.org" target="_blank">benjamin@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

2012/9/30 Xavier Morel <<a href="mailto:python-dev@masklinn.net">python-dev@masklinn.net</a>>:<br>
<div class="im">> But at worst, an outdated unicode database will be missing data right?<br>
><br>
> Doesn't an outdated timezone db have the risk of returning *incorrect* data?<br>
<br>
</div>Unicode updates also include corrections; however, it seems there are<br>
not significant enough or about obscure enough scripts that not many<br>
notice. :)<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>We never hear anyone complain because the corrections are not for English or other "western" languages that the majority of us speak.  ;)</div>

<div><br></div><div>Regardless, I think including a version of the database on windows releases makes sense.  Update it on a best effort basis before each .x minor release.  The documentation can make it clear that it is a changing database how to use an updated version with your application.</div>

<div><br></div><div>One additional thing I'd like to see: Don't let the successful importing of a 'pytzdata' module be the only way to get an updated tz database.  Create an API for someone to supply one themselves at runtime that is cleaner than shoving something into sys.modules['pytzdata'].  And define in which order they'll be used:</div>

<div><br></div><div>priority:</div><div>  1) api call supplying tz data to the process.</div><div>  2) pytzdata module if it exists</div><div>  3) tz data from the underlying operating system</div><div>  4) error.</div><div>

<br></div><div>-gps</div><div><br></div><div>PS Unicode data is political as well, just less politically active than stupid time zones and "savings" times.</div></div>