On Fri, Sep 18, 2015 at 11:19 PM, Akira Li <[email protected]> wrote:
> It was > a reaction to the earlier message in this thread, to point out why > stdlib's fromutc() API is not the example that should be followed. > You don't have to "follow" it but you must understand what datetime module expects from you as a tzinfo implementer if you decide to override the default fromutc() implementation. What Stuart did in pytz was a hack that the authors of the original design did not expect. I think you find fromutc() design unnatural because you have a different view of what datetime instances are. I believe for you, datetime instances are labels on a time line, but they are not. They are more like clock faces. Aware datetimes are clocks with stickers that say "New York", "Madrid", etc. The label tells you how to interpret the time that the clock shows, but that time does not have to be "current" or "accurate" time at the location written on the label. You can take a "Madrid" clock and set it to show "current" New York time. Nothing in datetime module will stop you even if you set the time that falls in Madrid "gap" and makes no sense there. The fromutc() method helps you to set your New York clock if you know "current" UTC time. The instructions are simple: set "current" UTC time on your New York clock and call fromutc(). If you adopt this mental picture, then the idea of replacing tzinfo on a datetime becomes absurd. Why would you want ruin a perfectly good "New York" clock simply because it comes from Geneva showing time that is 5 hours ahead? You don't rip off the "New York" label - you just wind the clock back 5 hours.
_______________________________________________ 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/
