On Fri, Jul 31, 2015 at 1:09 PM, Ethan Furman
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