On Fri, Jul 31, 2015 at 1:09 PM, Ethan Furman <ethan@stoneleaf.us> wrote:

Personally I think what we have is pretty good.

We can shore up the cracks with a new tzinfo object to handle actual durations across time skips.

We can add a datedelta to handle things like weeks and months and years -- if we need to. I think the first step is the new tzinfo, and after that it seems there are already a bunch of third-party modules to handle "human time" calculations.

Fair enough. Specifying that you want Duration Arithmetic in a time zone object seems pretty kludgy to me -- after all, it has nothing to do logically with what time zone you are in. But it does seem like the least disruptive way to patch it into the current system.

And datetime + timedelta, does, in fact, already provide Duration Arithmetic for naive datetimes.

And I just noticed that dateutils has:

"""

Timezone (tzinfo) implementations for tzfile(5) format files (/etc/localtime, /usr/share/zoneinfo, etc), TZ environment string (in all known formats), iCalendar format files, given ranges (with help from relative deltas), local machine timezone, fixed offset timezone, UTC timezone, and Windows registry-based time zones.
"""

(as well, I think, as a build-in Olson database)

I have no idea how robust it is, but it looks like it's got everything we need to put time zones into the stdlib...

(and a PeriodDelta type...)

-CHB

--
~Ethan~
_______________________________________________
Datetime-SIG mailing list
Datetime-SIG@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@noaa.gov