[Datetime-SIG] PEP-0500 (Alternative datetime arithmetic) Was: PEP 495 ... is ready ...
chris.barker at noaa.gov
Sat Aug 22 23:35:39 CEST 2015
On Thu, Aug 20, 2015 at 1:38 PM, ISAAC J SCHWABACHER <ischwabacher at wisc.edu>
> 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
Do pytz or datetutils let you construct a tzinfo instance from "EST" or the
(if the answer is no -- no need to drag the thread out...)
> 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=
> wisc.edu at python.org> on behalf of Alexander Belopolsky <
> alexander.belopolsky at gmail.com>
> *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 <lrekucki at gmail.com>
> > 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
> > 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",  "%Z -
> Time zone name (no characters if no time zone exists), "  "tm_zone -
> abbreviation of timezone name,"  "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."  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. :-)
> : https://docs.python.org/3/library/time.html#time.strftime
> : https://docs.python.org/3/library/time.html#time.struct_time
> : https://docs.python.org/3/library/time.html#time.tzname
> Datetime-SIG mailing list
> Datetime-SIG at python.org
> The PSF Code of Conduct applies to this mailing list:
Christopher Barker, Ph.D.
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
Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Datetime-SIG