On Thu, Aug 20, 2015 at 1:38 PM, ISAAC J SCHWABACHER <[email protected]> wrote:
> The problem with abbreviations like "CET" isn't that they don't represent > time zones; the problem is that they're not unique. > exactly -- and I don't know what vocabulary we should use, but maybe a nice recursive definition for this discussion: A timezone is the thing that a tzinfo object represents" would do it. but then I don't know what words to use to describe the other "things" we need to talk about... > 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. > Is anyone pr0posing that? I know I find notations like "EST" helpful in daily life: This memo was written at "5:27pm EDT" It's clear to an American, anyway, what that means (and I"m from Seattle, but happen to be in Boston now, so it's actually kind of helpful :-) ) But those notations are strictly one way streets -- not very useful if you want to construct an aware datetime instance from them -- at least without more info. Do pytz or datetutils let you construct a tzinfo instance from "EST" or the like? (if the answer is no -- no need to drag the thread out...) -CHB > > 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 <datetime-sig-bounces+ischwabacher= > [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]> > 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/ > -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected]
_______________________________________________ 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/
