<div class="gmail_quote">On Fri, Dec 28, 2012 at 10:12 PM, Ronald Oussoren <span dir="ltr"><<a href="mailto:ronaldoussoren@mac.com" target="_blank">ronaldoussoren@mac.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
On 28 Dec, 2012, at 21:23, Lennart Regebro <<a href="mailto:regebro@gmail.com">regebro@gmail.com</a>> wrote:<br>
<br>
> Happy Holidays! Here is the update of PEP 431 with the changes that emerged after the earlier discussion.<br>
<br>
</div>Why is the new timezone support added in a submodule of datetime? Adding the new<br>
function and exception to datetime itself wouldn't clutter the API that much, and datetime<br>
already contains some timezone support (datetime.tzinfo).</blockquote><div><br>Putting the API directly into the datetime module does conflict with the new timezone class from Python 3.2. The timezone() function therefore needs to be called something else, or the timezone class must be renamed.<br>

<br>Alternative names for the timezone() function is get_timezone(), which has already been rejected, and zoneinfo() which makes it clear that it's only zoneinfo timezones that are relevant.<br>Or the timezone class get's renamed TimeZone (which is more PEP8 anyway). <br>

<br>We can allow the timezone() function to take both timezone(offset, [name]) as now, and timezone(name) and return a TimeZone object in the first case and a zoneinfo based timezone in the second case.<br><br>Or maybe somebody else can come up with more clever options?<br>

</div></div>