On Wed, Aug 19, 2015 at 9:18 PM, Tim Peters <[email protected]> wrote:
> > If "include a string mnemonically distinguishing daylight from standard > > time" is an actual requirement for the product that they need to ship, > > I am sure they will appreciate seeing that this can be achieved by > > adding .astimezone() in a few strategic places. > > For Pythons already released, yes, they'll appreciate that - although > most people with such a requirement in a serious application is > probably already using pytz, where they've already added pytz's "force > the magical standard/daylight string switch" dance. 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.
_______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
