<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 19, 2015 at 9:18 PM, Tim Peters <span dir="ltr"><<a href="mailto:tim.peters@gmail.com" target="_blank">tim.peters@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> If "include a string mnemonically distinguishing daylight from standard<br>
> time" is an actual requirement for the product that they need to ship,<br>
> I am sure they will appreciate seeing that this can be achieved by<br>
> adding .astimezone() in a few strategic places.<br>
<br>
</span>For Pythons already released, yes, they'll appreciate that - although<br>
most people with such a requirement in a serious application is<br>
probably already using pytz, where they've already added pytz's "force<br>
the magical standard/daylight string switch" dance.</blockquote></div><br>Maybe or maybe not.  Shipping pytz with your product means becoming a TZ database distributor for your customers.  More likely they have an in-house equivalent of .astimezone() on top of time.localtime() or a direct call to system localtime if their code predates us exposing tm_zone and friends in time.localtime().   In this case, they can switch to the now available .astimezone() and have fewer lines of proprietary code to support. </div></div>