The problem with abbreviations like "CET" isn't that they don't represent time zones; the problem is that they're not unique. CST is probably Central Standard Time... unless it's China Standard Time or Cuba Standard Time. There are plenty of other examples. We can't stop people from using these, and we shouldn't refuse to support them out of spite, but if we present to users one obvious way to do it that forces us to guess in the face of this ambiguity, I'd argue that that's bad design.
ijs Top-posted from Microsoft Outlook Web App; may its designers be consigned for eternity to that circle of hell in which their dog food is consumed. ________________________________ From: Datetime-SIG <[email protected]> on behalf of Alexander Belopolsky <[email protected]> Sent: Thursday, August 20, 2015 09:53 To: Łukasz Rekucki Cc: datetime-sig Subject: Re: [Datetime-SIG] PEP-0500 (Alternative datetime arithmetic) Was: PEP 495 ... is ready ... On Thu, Aug 20, 2015 at 1:33 AM, Łukasz Rekucki <[email protected]<mailto:[email protected]>> wrote: > > You have read this totally backwards. The quote says that the time zone can > NOT be seen as a simple UTC offset +/-DST (which is a common misconception > that can be seen on many "timezone" maps). As an example CET is given - it's > not a timezone as it consist of "Europe/Warsaw", "Europe/Berlin", etc. By your logic, UTC is not a time zone either because it "counsists of" Europe/London, Africa/Casablanca etc. This is a very unorthodox point of view. > > From datetime implementation perspective Tim's definition is the best, but > from perspective of a implementing a timezone database a thing like CET or > -0500 is just ambiguous because it means one of many actuall timezones. Whatever your definition of "actual timezone" is, if you want to use Python effectively you need to understand the terms as they are used in the library manual. And there we have, for example: "%Z - Time zone name (empty string if the object is naive) - (empty), UTC, EST, CST", [1] "%Z - Time zone name (no characters if no time zone exists), " [2] "tm_zone - abbreviation of timezone name," [3] "time.tzname - A tuple of two strings: the first is the name of the local non-DST timezone, the second is the name of the local DST timezone." [4] and so on. You can insist that CET is not a timezone as much as that 0 is not a number, but as far as Python timekeeping goes, timezone is whatever Tim says it is. (Those who disagree can think of Python timezones as TIMezones. :-) [1]: https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior [2]: https://docs.python.org/3/library/time.html#time.strftime [3]: https://docs.python.org/3/library/time.html#time.struct_time [4]: https://docs.python.org/3/library/time.html#time.tzname
_______________________________________________ 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/
