On Wed, Aug 19, 2015 at 8:16 PM, Tim Peters <[email protected]> wrote:
> I propose to end the argument about what "time zone" means by > insisting it means whatever I think it means, and that's the end of it > ;-) > +1 > > Specifically, a time zone is a function mapping UTC calendar notation > to another (possibly identical) calendar notation. > I would not got a far as allowing say a function that swaps minutes and seconds in "time zone" definition, but as long as we agree that datetime.timezone is, umm, a "time zone", I am happy with your definition. > > For some purposes, the destination's idea of "calendar notation" > includes strings like "America/Chicago" or "CDT"/"CST", and in others > it may only include a notion of a fixed UTC offset (like "-05:00"). > I don't think anyone here denies that there is more than fixed UTC offset timezones. It just so happened that this is all that CPython ships in the standard library. > > All are valid "time zones", and, e.g., someone insisting that their > idea of calendar notation must magically include a string mnemonically > distinguishing daylight from standard time is on ground just as solid > as anyone else. > Absolutely right. > > Telling them they "shouldn't" insist on that won't work. Showing them > it's easily obtained by other means also won't work. > > I am more optimistic than you are on that. 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. > Unless, of course, their idea of "time zone" is "how civil time > actually works" ;-) >
_______________________________________________ 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/
