[Datetime-SIG] PEP-0500 (Alternative datetime arithmetic) Was: PEP 495 ... is ready ...

[Chris Barker]

On Thu, Aug 20, 2015 at 1:38 PM, ISAAC J SCHWABACHER <ischwabacher at wisc.edu>
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=
> 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>
> 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
> Datetime-SIG at python.org
> 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

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150822/0ad10a52/attachment-0001.html>