Mailman 3 July 2015 - Datetime-SIG

Re: [Datetime-SIG] What's are the issues?
by Felipe Ochoa 28 Jul '15

28 Jul '15

In the interest of continuing to lay the foundation for discussion, let me build on Chris's recap before giving my viewpoint on the issue: 1. Datetime arithmetic >> a) datetime +/- timedelta >> ii. Aware (with tzinfo) datetime objects > > If the math is done in UTC, then there is no issue, yes? the timedelta is > added or subtracted, and the result has the same tzinfo object. If I've understood correctly, this is one of the bigger points of contention. Specifically, the following operation is quite polarizing: `datetime(2015, 3, 7, 13, 0, tzinfo=zoneinfo('America/New_York') ) + timedelta(days=1)` It raises the following two questions: * Should `days=1` be interpreted the same as `hours=24`? * If it is interpreted the same, should the addition be "naive" (not adjusting for the jump from 1:59 to 3:00) or "aware" Current semantics call for the answers to be "yes" and "naive" > b) datetime - datetime > > ii. When both have same tzinfo > > Just do the math. Store as UTC makes it easy. return a timedelta. This is another contentious issue. What do you want `datetime(2015, 3, 8, 13, tzinfo=zoneinfo('America/New_York')) - datetime(2015, 3, 7, 13, tzinfo=zoneinfo('America/New_York'))` to be? There's a camp for `timedelta(seconds=24 * 60 * 60)` and a camp for `timedelta(seconds=23 * 60 * 60)`, though I think everyone agrees that `(dt + delta) - dt == delta` is necessary. 2. Inter-timezone conversion > > b) algorithm specification > > what part of the algorithm? seems pretty straightforward to me (the > algorithm, anyway) I'm less clear on the issue here, but Isaac seemed to disagree with the algorithm in datetime.py ( https://hg.python.org/cpython/file/v3.5.0b1/Lib/datetime.py#l1935) [ http://code.activestate.com/lists/python-dev/137300/]

1 0

Re: [Datetime-SIG] What's are the issues?
by Alexander Belopolsky 28 Jul '15

28 Jul '15

On Tue, Jul 28, 2015 at 5:38 PM, Felipe Ochoa <felipe.nospam.ochoa(a)gmail.com> wrote: > > Here is my best shot at categorizing the different outstanding design issues: > I would like to make sure that everyone is aware that we are not designing in a vacuum. Unlike Python 2, Python 3 already has a decent amount of timezone support. In fact, with some small exceptions, I believe Python 3 datetime has a fairly complete support for UTC and system local timezones. For the items below, I will try to briefly describe the status quo > 1. Datetime arithmetic > a) datetime +/- timedelta > i. Naive (no tzinfo) datetime objects This has been supported from the very beginning: >>> t = datetime.now() >>> t datetime.datetime(2015, 7, 28, 19, 18, 59, 699588) >>> t + timedelta(1) datetime.datetime(2015, 7, 29, 19, 18, 59, 699588) (no surprises here) > ii. Aware (with tzinfo) datetime objects This works fine with the builtin timezone instances: >>> t = datetime(2014,11,1,16,tzinfo=timezone.utc).astimezone() >>> t.strftime("%c %Z %z") 'Sat Nov 1 12:00:00 2014 EDT -0400' >>> u = t + timedelta(1) >>> u.strftime("%c %Z %z") 'Sun Nov 2 12:00:00 2014 EDT -0400' This may be a little surprising to those expecting to see DST to end, but the legal time is one method call away: >>> u.astimezone().strftime("%c %Z %z") 'Sun Nov 2 11:00:00 2014 EST -0500' > b) datetime - datetime > i. When both are naive (Trust me: this part works!) > ii. When both have same tzinfo >>> u - t datetime.timedelta(1) (Works.) > iii. When the two have different tzinfos >>> u - datetime(2014,11,1,16,tzinfo=timezone.utc) datetime.timedelta(1) (Works as well.) > 2. Inter-timezone conversion UTC to local just works. Local to UTC "kind of" works: >>> t = datetime.now() >>> u = datetime.fromtimestamp(t.timestamp(), timezone.utc) >>> u.strftime("%c %Z") 'Tue Jul 28 23:40:38 2015 UTC+00:00' > a) adding an isdst (or which) attribute > b) algorithm specification > > I think 1ai, 2bi, and 1biii are uncontroversial at this point, and 2a we have consensus on the need but not the name >

1 0

Re: [Datetime-SIG] What's are the issues?
by Ethan Furman 28 Jul '15

28 Jul '15

On 07/28/2015 01:58 PM, Chris Barker wrote: > Now that we have a datetime list, maybe it's time to re-center ourselves. > > I know I got all caught up in the semantics and details, but I just now gave the PEP another read-through, and, well, it looks good to me. > > What are the issues still to be resolved? I think the biggest issue is that Lennart was trying to change the way datetimes work, which a. would be a compatibility break b. is not clear from the PEP I think a lot of confusion comes from the necessity of using timedeltas as a time measurement device, even when we aren't really using them that way -- meaning when we add a timedelta of 7 days to go from Jun 27 09:00 to Jul 4 09:00 we (usually) don't care if that is exactly 7 * 24 hours later. I think the ideal solution would be to have tz-aware datetimes able to switch their timezone as needed, but that would also be a backwards-compatibility break -- not to mention the need to be able to specify whether one wants the "calendar" operation (7am is still 7am) or the actual duration operation (7am may be 6am or 8am if a clock change occurs). On the gripping hand we already have the calendar semantics, so perhaps just a whole new type of datetime would be best? -- ~Ethan~

1 0

Re: [Datetime-SIG] What's are the issues?
by Chris Barker 28 Jul '15

28 Jul '15

On Tue, Jul 28, 2015 at 2:38 PM, Felipe Ochoa <felipe.nospam.ochoa(a)gmail.com > wrote: > Here is my best shot at categorizing the different outstanding design > issues: > great, thanks! My thoughts: (some obvious) NOTE: I'm assuming that timedelta is the same as it is now -- i.e. "naive", or simply representing a timespan nothing t do with calendars. 1. Datetime arithmetic > a) datetime +/- timedelta > i. Naive (no tzinfo) datetime objects > same as now > ii. Aware (with tzinfo) datetime objects > If the math is done in UTC, then there is no issue, yes? the timedelta is added or subtracted, and the result has the same tzinfo object. > b) datetime - datetime > i. When both are naive > same as now. > ii. When both have same tzinfo > Just do the math. Store as UTC makes it easy. return a timedelta. > iii. When the two have different tzinfos > Do the math in UTC, return a timedelta. > 2. Inter-timezone conversion > a) adding an isdst (or which) attribute > yup -- and I've bike-shedeed enough without getting into what to call it! > b) algorithm specification > what part of the algorithm? seems pretty straightforward to me (the algorithm, anyway) So really a lot of bike-shedding on pyton-dev ;-) -CHB -- 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(a)noaa.gov

1 0

Re: [Datetime-SIG] What's are the issues?
by Felipe Ochoa 28 Jul '15

28 Jul '15

Here is my best shot at categorizing the different outstanding design issues: 1. Datetime arithmetic a) datetime +/- timedelta i. Naive (no tzinfo) datetime objects ii. Aware (with tzinfo) datetime objects b) datetime - datetime i. When both are naive ii. When both have same tzinfo iii. When the two have different tzinfos 2. Inter-timezone conversion a) adding an isdst (or which) attribute b) algorithm specification I think 1ai, 2bi, and 1biii are uncontroversial at this point, and 2a we have consensus on the need but not the name On 28 July 2015 at 15:58, Chris Barker <chris.barker(a)noaa.gov> wrote: > Hi folks, > > Now that we have a datetime list, maybe it's time to rre-center ourselves. > > I know I got all caught up in the semantics an details, but I just now > gave the PEP another read-through, and, well, it looks good to me. > > What are the issues still to be resolved? > > -Chris > > > > -- > > 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(a)noaa.gov > > _______________________________________________ > Datetime-SIG mailing list > Datetime-SIG(a)python.org > https://mail.python.org/mailman/listinfo/datetime-sig > >

1 0

What's are the issues?
by Chris Barker 28 Jul '15

28 Jul '15

Hi folks, Now that we have a datetime list, maybe it's time to rre-center ourselves. I know I got all caught up in the semantics an details, but I just now gave the PEP another read-through, and, well, it looks good to me. What are the issues still to be resolved? -Chris -- 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(a)noaa.gov

1 0

Calendar vs timespan calculations...
by Chris Barker 28 Jul '15

28 Jul '15

Moved from python-dev to the datetime SIG TL;DR: There are are two types of operations on datetimes: adding subtracting actual time units (multiples of seconds) and calendar operations: things like "this time the next day". I think the the datetime module should only support the former -- i.e. the same old timedelta we have. In that context, storing datetimes in UTC, doing all operations there, and converting back makes the most sense. But for calendar manipulations, they need to be done in a time-zone aware way. If you're really interested, I got quite carried away below.... On Mon, Jul 27, 2015 at 10:03 PM, Lennart Regebro <regebro(a)gmail.com> wrote: > On Tue, Jul 28, 2015 at 12:03 AM, Tim Peters <tim.peters(a)gmail.com> wrote: > > timedelta objects only store days, seconds, and microseconds, > > Except that they don't actually store days. They store 24 hour > periods, which, because of timezones changing, is not the same thing. > yes, it is ;-) And as you have repeated > many times now, the datetime module's arithmetic is "naive" ie, it > assumes that one day is always 24 hours. The problem with that > assumption is that it isn't true. > it's not an assumption, it's a definition. We have a serious semantic problem here -- and I _think_ it's the source of almost all the discussion in this thread -- I'm not sure what to do about it though. Tim understands this stuff, Lennart understands this stuff, I'm pretty sure I understand this stuff -- I'm not sure about everyone else on this discussion, but they probably all understand it, too -- the only thing any of us doesn't understand is what the heck anyone is talking about! Maybe use Tim's approach of "naive" -- so a naive day is exactly 24 hours period end of story -- this is the definition. But what do we call what I've been trying to refer to as "calendar" operations? A summary for (maybe) some clarity: We have this nifty model of a continuous time axis -- moving along at a steady rate from the beginning of the Universe to the end of the Universe. Modulo relativity, it works pretty well. Then we have units of time spans: in SI units it's seconds. then a bunch of other units that are clearly defined in terms of seconds: minutes (60 s) hours (60 min) days (24 hrs). And of course milliseconds and microseconds. Then we have Calendars: this is the year, month, day, etc. we are all familiar with (and the hours in that day 4:00 o'clock pm, etc) -- confusing here is that we use the same word for "day" and "hour" as part of a calendar descriptions AND also as timespan units -- but they are NOT the same thing (yes, they are related). Calendars are how we map a nice human understandable (and historically based) naem onto the theoretically time axis. Being both human-oriented and with a lot of historical baggage, calendar naming is designed to fit more or less with relationship between the earth and the sun. So we want the Solstices to fall around the same date every year, for instance, and we want 1200 hrs to be around the middle of the day. This is why it all gets ugly, because the various celestial phenomena aren't nice integers multiples of each-other (hence the need for leap years) and even constant (hence the need for leap seconds). And, of course, the earth is round, and the sun's relative position to each point on earth is different, hence the need for time zones. (then add political differences for it to get really ugly. So: I think there are more or less two types of manipulations one might need: What is currently supported by the datetime module, and I think Tim is referring to as "naive" time operations: adding, subtracting, units of time along the theoretical time axis. This is actually really simple math -- as Tim points out all the timedelta object really is is a fancy integer. Then there are what I am calling "calendar" operations -- these are operations that only make sense with a calendar (and, in fact a timezone, I think). this is operations like: "the same time two days later" -- this is not the same as moving two days (48 hrs) along the time axis -- it simply is not. It is a shame that we use the name "day" to refer to both 24 hours along the time axis and enumeration of sunrises in a month -- or, the thing we use on calendars. There has been a lot of chatter about "tomorrow" or "adding three days", as these bring up the ugly DST issues, but once you add one calendaring operation, people will want (and they should) more: next month, next year, or even uglier, next business day, etc. These are very useful things, but I argue they belong, as a unit, in a separate package -- maybe for potential inclusion in the standard library, but I don't think that's on the table now. (and doesn't dateutil support many of these?) Now on to time zones: the datetime package is useful because it not only supports time-axis arithmetic (really pretty trivial -- it's just integer arithmetic), but it supports translating from time-axis units (microseconds since some epoch) to Calendar units: year, month, day, hour, minute, seconds, microseconds (Using the (proleptic?) Gregorian Calendar -- note that different Calendars are a whole other ball of wax! This is where the magic is (or really where the ugly code is) , and where tiem zones come in. UTC time is the calendar time at one longitude on the earth. (ignoring leap seconds for the moment) it is relatively simple: continuous, etc, no DST, no changing definitions, etc. It is a useful reference system for this reason. math, and all that, are easier in this zone. By default, Python datetime objects are "naive" -- meaning they know nothing of timezones or daylight savings -- they can convert back and forth between the internal representation (time span since an epoch) and human calendar times (Gregorian, anyway). It turns out that you can use naive datetimes as UTC time -- there really is no difference, until you want to convert to a different time zone -- with UTC, you may be able to do that, with naive, you can't do that unless you specify what time zone the time is, and then it's no longer naive ;-) But how should pyton handle time zones? Given all the ugliness of DST and changing time zones, and all that, UTC is the lingua franca of time -- time zones are defined by how the are offset from UTC, and in UTC (as in naive), math is relatively easy. So the best way to handle time zones is to store and manipulate everything in UTC, and then convert to/from the calendar representation using the time zone, when the user needs (or provides). I've been trying to figure out what all the confusion, discussion has been about, and I think it's this: If you want to do a Calendar operation, like "this time tomorrow", then THAT is best done in a timezone aware way -- in particular, a DST-aware way. i.e. from 12:00 one day to 12:00 the next day will generally be 24 hours, but might be 23 or 25 hours if crossing a DST transition. But if we aren't supporting those operations, we don't need to worry about that now. -Chris > _______________________________________________ > Python-Dev mailing list > Python-Dev(a)python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov > -- 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(a)noaa.gov

1 0