Mailman 3 July 2015 - Datetime-SIG

Re: [Datetime-SIG] Clearing up terminology
by Tim Peters 30 Jul '15

30 Jul '15

[Guido] > ... > I also never meant the term "naive" to be used for the existing arithmetic > rules for tz-aware datetime objects -- I always meant "naive" to refer to > tz-less datetime objects. "Naive arithmetic" was my neologism, starting in this batch of messages. The docs don't call the arithmetic anything, or acknowledge that more than one kind of arithmetic is possible. This batch of messages needed to call it _something_, so I made something up. The docs do briefly explain the "native time" _model_ (and acknowledge that more than one kind of model is possible). The kind of arithmetic Python implements is the only kind that delivers correct answers _within_ the naive time model,. so I've been calling it "naive arithmetic" - in the sense of "the arithmetic behavior required by the naive time model". Which is an unfortunate verbal mess, in large part because "naive arithmetic" is used for _both_ what the docs call "naive objects" and "aware objects". Then again, calling _anything_ "naive" in the docs was probably also unfortunate from the start ;-) > I would prefer something like "classic arithmetic" for tz-aware datetime objects. Read literally, that doesn't make sense to me, and I can't tease out the intent. That is, calling an object (whatever it is) a kind of arithmetic (whatever it is) doesn't make sense to me. I had guessed, that you wanted to call the kind of _arithmetic_ currently implemented "classic arithmetic". but in the next sentence you seem to want to call that "human arithmetic": > We can then introduce two new terms for different forms of arithmetic: > "human arithmetic" for the form that can do things like "+ 2 months" in a > way that (mostly) matches human expectations, and "strict arithmetic" for > the form that Lennart needs (essentially move a specific number of seconds > along UTC). Do you really intend that we use all three: "classic arithmetic", "human arithmetic", and "strict arithmetic"?. If so, I don't grasp the intended distinction between "classic" and "human".(both seem to be the same as what I've been calling "naive arithmetic": the arithmetic Python currently implements for binary arithmetic operators involving at least one datetime object). Anyway, because "strict arithmetic" more-or-less literally means "arithmetic that wholly satisfies the requirements of a given model", in isolation the phrase leaves the question of _which_ model open. So, as was suggested later in the thread, I'd prefer "timeline arithmetic" (and couldn't care less whether it's called "timeline", "time line", or both). And I'll conveniently overlook that "timeline arithmetic" on its own leaves open _which_ timeline (naive or timezone) is intended ;-) > FWIW (not much, we're stuck with it now), my intention with classic > arithmetic was to approximate human arithmetic, but only for cases that > didn't require messy heuristics such as "Feb 29, 2016 plus one year" or "Jan > 31, 1956 minus 9 months". I always viewed the _model_ ("naive time") as primary. Specific arithmetic requirements (for builtin arithmetic operators) then necessarily followed from the choice of model. In any case, while mixed datetime/timedelta arithmetic supports only a small subset of what people want in the way of "calendar operations", it is an exceedingly useful subset on its own, _and_ in implementing fancier operations. It was a great start. ... > I also (naively :-) assumed that people interested in strict arithmetic would > just keep using the POSIX timestamps used by the time module. >> (BTW, historically, early versions of Python datetime had a separate >> datetime subclass called datetimetz (IIRC), but the final design got >> rid of this unnecessary complexity.) > I don't believe that was ever released, but it's possible we contemplated > that and even implemented it in an early pure-Python prototype. FWIW, IIRC it did exist in an early prototype but was discarded before it was even halfway implemented.

1 0

Re: [Datetime-SIG] Clearing up terminology
by ISAAC J SCHWABACHER 30 Jul '15

30 Jul '15

> From: Datetime-SIG <datetime-sig-bounces+ischwabacher=wisc.edu(a)python.org> on behalf of Chris Barker <chris.barker(a)noaa.gov> > Sent: Wednesday, July 29, 2015 19:14 > To: Felipe Ochoa > Cc: datetime-sig > Subject: Re: [Datetime-SIG] Clearing up terminology > > Then there seem to be the big hang-up: people want a way to define Periods (as defined above) and want to be able to do datetime math with them. I"m still really confused as to why folks seemed to think "time zone aware" somehow meant using Peiods rather than Durations for arithmetic, but there you go. Clearly this is very useful thing to have, but it's NEW feature, and not covered in the PEP. I think you're missing something here. This *isn't* the current behavior-- adding a 24 hour timedelta (a Duration) to an aware datetime (a ZonedDateTime) *doesn't* produce an aware datetime corresponding to the Instant 24 hours after the Instant corresponding to the first datetime; rather, it produces an aware datetime equal to the first but with its days field incremented by one. This result corresponds to an Instant that may be 23 or 25 hours (or some weirder number, in exceptional cases) after the first Instant. Which is to say, currently, datetime.timedelta behaves neither as a Period nor as a Duration. In order to use it as a Duration, you need to convert to UTC before doing arithmetic and convert back after. *That* is what has people up in arms. ijs

1 0

Re: [Datetime-SIG] Clearing up terminology
by Alexander Belopolsky 30 Jul '15

30 Jul '15

On Thu, Jul 30, 2015 at 10:05 AM, Guido van Rossum <guido(a)python.org> wrote: > [Alexander Belopolsky] > >> >> As far as I understand, NodaTime to Python dictionary would have the >> >> following translations: >> >> >> >> LocalDatetime: datetime with tzinfo=None (naive datetime) >> > >> > That's all fine, but my point remains, that the tz-less datetime object > does *not* always mean local time. The definition I quoted from Alexander > conflated the two, incorrectly IMO. > I agree with that, but it is my understanding that Noda's LocalDatetime concept most closely matches our "naive datetime" concept. According to Noda documentation, LocalDatetime is "A date and time in a particular calendar system. A LocalDateTime value does not represent an instant on the time line, because it has no associated time zone: "November 12th 2009 7pm, ISO calendar" occurred at different instants for different people around the world." [1] Since it "has no associated time zone," it "does *not* always mean local time" even thought it has "Local" in the name. [1]: http://nodatime.org/1.2.x/api/html/T_NodaTime_LocalDateTime.htm

1 0

Re: [Datetime-SIG] Clearing up terminology
by ISAAC J SCHWABACHER 30 Jul '15

30 Jul '15

> From: Datetime-SIG <datetime-sig-bounces+ischwabacher=wisc.edu(a)python.org> on behalf of Alexander Belopolsky <alexander.belopolsky(a)gmail.com> > Sent: Wednesday, July 29, 2015 19:27 > To: Felipe Ochoa > Cc: datetime-sig > Subject: Re: [Datetime-SIG] Clearing up terminology > > On Wed, Jul 29, 2015 at 5:31 PM, Felipe Ochoa > <felipe.nospam.ochoa(a)gmail.com> wrote: > > * Time zone: "a mapping from UTC instants to offsets" > > > > * Offset: "simply the difference between UTC and local time." > > > > * ZonedDatetime: An instant + a time zone > > > > * OffsetDatetime: An instant + an offset (which is not the same as a > > ZonedDatetime!) > > > > * LocalDatetime: A date/time in the usual "naive" sense: a combination of > > year, month, day, hour, minute, second, millisecond (soon to be nano?) > > Given this terminology and the following UNIX date utility invocation, > > $ TZ=Australia/Melbourne date +"%c%z" > Thu 30 Jul 2015 10:21:18 AM EST+1000 > > what is (a) Australia/Melbourne, (b) EST? Australia/Melbourne is a time zone, +1000 is an offset, and EST is an accident waiting to happen. ijs

1 0

Re: [Datetime-SIG] Clearing up terminology
by Guido van Rossum 30 Jul '15

30 Jul '15

[Alexander Belopolsky] > >> As far as I understand, NodaTime to Python dictionary would have the > >> following translations: > >> > >> LocalDatetime: datetime with tzinfo=None (naive datetime) > [Guido van Rossum] > > I have a slight concern here. In my own brain-universe there is a > difference > > between a *local* datetime and a *naive* datetime. A local datetime has > an > > implicit timezone (the one used by the system wall clock, or perhaps the > TZ > > env var). A naive datetime, as intended in the original design, has *no* > > timezone. > [Łukasz Rekucki] > If the timezone is implicit, then it's not kept together with the > object. Which means that the difference is purely in the behavior of > such object, e.g. converting to UTC: naive datetime requires passing a > timezone explicitly, while your local datetime just call > get_system_timezone() and uses that. I would say if you have both a > *naive* datetime and "*zoned* datetime, the use of this kind of > datetime with implicit timezone is rather limited because you can just > use a *zoned* variant with get_system_timezone() as its TZ > _explicitly_. > That's all fine, but my point remains, that the tz-less datetime object does *not* always mean local time. The definition I quoted from Alexander conflated the two, incorrectly IMO. [Guido] > > I also never meant the term "naive" to be used for the existing > arithmetic > > rules for tz-aware datetime objects -- I always meant "naive" to refer to > > tz-less datetime objects. I would prefer something like "classic > arithmetic" > > for tz-aware datetime objects. > > > > We can then introduce two new terms for different forms of arithmetic: > > "human arithmetic" for the form that can do things like "+ 2 months" in a > > way that (mostly) matches human expectations, and "strict arithmetic" for > > the form that Lennart needs (essentially move a specific number of > seconds > > along UTC). > > How about *time line* arithmetic ? It's also in Noda docs and avoids > discussing what is more "human". But "strict" sounds good too. > If that's what Noda uses, that's fine with me (the fewer vocabularies the better). > Is there some wiki-space where this could be put to so that people > don't have too search the archives? (I'm willing to do the work and > gather the info from this thread into it). Wikis are self-serve. Create one! -- --Guido van Rossum (python.org/~guido)

1 0

Re: [Datetime-SIG] Clearing up terminology
by Łukasz Rekucki 30 Jul '15

30 Jul '15

On 30 July 2015 at 10:54, Guido van Rossum <guido(a)python.org> wrote: > Thanks to Felipe Ocha for posting the nodatime link -- it's very useful. (I > first misread it as "no datetime". :-) > > On Thu, Jul 30, 2015 at 4:10 AM, Alexander Belopolsky > <alexander.belopolsky(a)gmail.com> wrote: >> >> [...] >> Another way to tell that "EST" is a "time zone" is because it is valid >> as a TZ environment variable value: >> [...] > > > Can we be more precise here and distinguish between a "time zone" (which is > a function from UTC to offsets) and the various *names* for time zones? It > seems that there are multiple names for some (many) time zones, and some > names also designate multiple timezones (maybe those are known as "short > names"?). Presumably a good tz database has both the mappings between names > and functions, and the functions themselves (in some DSL involving offsets > and DST rules, of course). +1 >> >> As far as I understand, NodaTime to Python dictionary would have the >> following translations: >> >> LocalDatetime: datetime with tzinfo=None (naive datetime) > > > I have a slight concern here. In my own brain-universe there is a difference > between a *local* datetime and a *naive* datetime. A local datetime has an > implicit timezone (the one used by the system wall clock, or perhaps the TZ > env var). A naive datetime, as intended in the original design, has *no* > timezone. If the timezone is implicit, then it's not kept together with the object. Which means that the difference is purely in the behavior of such object, e.g. converting to UTC: naive datetime requires passing a timezone explicitly, while your local datetime just call get_system_timezone() and uses that. I would say if you have both a *naive* datetime and "*zoned* datetime, the use of this kind of datetime with implicit timezone is rather limited because you can just use a *zoned* variant with get_system_timezone() as its TZ _explicitly_. > > I also never meant the term "naive" to be used for the existing arithmetic > rules for tz-aware datetime objects -- I always meant "naive" to refer to > tz-less datetime objects. I would prefer something like "classic arithmetic" > for tz-aware datetime objects. > > We can then introduce two new terms for different forms of arithmetic: > "human arithmetic" for the form that can do things like "+ 2 months" in a > way that (mostly) matches human expectations, and "strict arithmetic" for > the form that Lennart needs (essentially move a specific number of seconds > along UTC). How about *time line* arithmetic ? It's also in Noda docs and avoids discussing what is more "human". But "strict" sounds good too. Is there some wiki-space where this could be put to so that people don't have too search the archives? (I'm willing to do the work and gather the info from this thread into it). -- Łukasz Rekucki

1 0

Re: [Datetime-SIG] Calendar vs timespan calculations...
by Guido van Rossum 30 Jul '15

30 Jul '15

On Thu, Jul 30, 2015 at 2:31 AM, Chris Barker <chris.barker(a)noaa.gov> wrote: > > Perhaps the original intent was that "days" means calendar days, and for > naive datetimes, it turns out to be the same thing, but that is not what > the implementation does, and given that it supports seconds and > microseconds, but not months or years, the API is pretty clearly designed > for timespans, not calendar definitions. > I can assure you that the implementation carefully matches the original intent. Even if I wouldn't design it that way today (which honestly I haven't decided whether I would or not) I don't want to change anything about the observable behavior[1] that would give a different outcome, no matter how much more "correct" you believe a different outcome would be. The deprecation time would have be measured in decades. The road to improvement that I encourage everyone to explore: add an is_dst flag (with a different name) and create new timedelta-ish classes that implement "human" arithmetic (similar to what pytz offers) and "strict" arithmetic (similar to [NJ]odaTime, IIUC). Separately, standardized access in the stdlib to a tz database (see another thread). [1] The *implementation* may change, but not in a way that changes observable behavior, except for the addition of new attributes, parameters and/or methods. -- --Guido van Rossum (python.org/~guido)

1 0

Re: [Datetime-SIG] Datetime - my issues
by Guido van Rossum 30 Jul '15

30 Jul '15

On Thu, Jul 30, 2015 at 5:33 AM, Tim Peters <tim.peters(a)gmail.com> wrote: > [...] > > You're using methods designed for interoperability with the C > language's ubiquitous "struct tm": > > http://pubs.opengroup.org/onlinepubs/007908775/xsh/time.h.html > > The meanings, and even the names of the fields, are identical between > Python and C. Actually the meanings of some fields are different -- C's tm_mon is 0-11, while Python's is 1-12; also, C's tm_year is "year - 1900" while Python's is the full 4-digit year (IIRC we had to change the latter in order to ward off Y2K issues). > A struct tm doesn't know microseconds from doughnuts. > That's why microseconds are missing here. But we could still add it. By now the similarity to C for various APIs is just there to help C programmers quickly get their bearings in Python, not a hard philosophical line in the sand. -- --Guido van Rossum (python.org/~guido)

1 0

Re: [Datetime-SIG] Clearing up terminology
by Guido van Rossum 30 Jul '15

30 Jul '15

Thanks to Felipe Ocha for posting the nodatime link -- it's very useful. (I first misread it as "no datetime". :-) On Thu, Jul 30, 2015 at 4:10 AM, Alexander Belopolsky < alexander.belopolsky(a)gmail.com> wrote: > [...] > Another way to tell that "EST" is a "time zone" is because it is valid > as a TZ environment variable value: > [...] > Can we be more precise here and distinguish between a "time zone" (which is a function from UTC to offsets) and the various *names* for time zones? It seems that there are multiple names for some (many) time zones, and some names also designate multiple timezones (maybe those are known as "short names"?). Presumably a good tz database has both the mappings between names and functions, and the functions themselves (in some DSL involving offsets and DST rules, of course). Also note that the functions themselves may change over time: when a local political body changes the rules. This is then reflected in an update of the tz database. There's a third mapping (which doesn't concern us much here) which also varies over time (and I don't know if the Olsen database has it): the mapping from geographical area to time zone. > As far as I understand, NodaTime to Python dictionary would have the > following translations: > > LocalDatetime: datetime with tzinfo=None (naive datetime) > I have a slight concern here. In my own brain-universe there is a difference between a *local* datetime and a *naive* datetime. A local datetime has an implicit timezone (the one used by the system wall clock, or perhaps the TZ env var). A naive datetime, as intended in the original design, has *no* timezone. What's the difference? A local datetime has a well-defined mapping to UTC, but a naive datetime's meaning is up to the app that manipulates it. An example might be a world-wide publicity event that happens at noon local time on a give date, or the broadcast time of a pre-recorded TV show (in the US, shows are often aired at a well-known time slot, e.g. "prime time", 8pm in each time zone). I also never meant the term "naive" to be used for the existing arithmetic rules for tz-aware datetime objects -- I always meant "naive" to refer to tz-less datetime objects. I would prefer something like "classic arithmetic" for tz-aware datetime objects. We can then introduce two new terms for different forms of arithmetic: "human arithmetic" for the form that can do things like "+ 2 months" in a way that (mostly) matches human expectations, and "strict arithmetic" for the form that Lennart needs (essentially move a specific number of seconds along UTC). FWIW (not much, we're stuck with it now), my intention with classic arithmetic was to approximate human arithmetic, but only for cases that didn't require messy heuristics such as "Feb 29, 2016 plus one year" or "Jan 31, 1956 minus 9 months". I also (naively :-) assumed that people interested in strict arithmetic would just keep using the POSIX timestamps used by the time module. > OffsetDatetime: datetime with tzinfo=datetime.timezone(offset, name) > ZonedDatetime: datetime with tzinfo=pytz.timezone(name) > > Given that all three concepts are implemented in a single > datetime.datetime class in Python, I am not sure how helpful NodaTime > terminology will be for our purposes. > They are still useful when discussing various use cases and scenarios. I bet several heated arguments of the past days would have been cut short more easily if these concepts had been explained earlier. Also, the distinction in terminology helps explain the difference between (e.g.) US EST and US/Eastern. > (BTW, historically, early versions of Python datetime had a separate > datetime subclass called datetimetz (IIRC), but the final design got > rid of this unnecessary complexity.) > I don't believe that was ever released, but it's possible we contemplated that and even implemented it in an early pure-Python prototype. -- --Guido van Rossum (python.org/~guido)

1 0

Re: [Datetime-SIG] Clearing up terminology
by Łukasz Rekucki 30 Jul '15

30 Jul '15

On 30 July 2015 at 02:14, Chris Barker <chris.barker(a)noaa.gov> wrote: > On Wed, Jul 29, 2015 at 2:31 PM, Felipe Ochoa >> >> * local vs global: "The key difference is that people all around the world >> will agree on a global value simultaneously, whereas they may all see >> different local values for the same global value, due to time zones." Local >> values are what Guido has labeled "naive" -- in the sense that they don't >> have a datetime. > > > Is this a typo? should be "don't have a time zone"? By the way, that means" > can't map to UTC, which, by extension, means, "can't map to any other > timezone" Yes, LocalDateTime does not have a timezone and thus does *not* define an instant on a timeline. You can't convert it to anything without providing extra information. >> >> * Time zone: "a mapping from UTC instants to offsets" > > > note that the actual mapping may (does) change over history, and has odd > things like DST. Yes, that's already covered in this definition. You can also say that a Timezone is a function from an Instant to offset. An example such function would look like this: def tz_us_cookie_time(instant): if instant.year() > 2016: return -5000 if 4 < instant.month() < 11 else -6000 else: return tz_us_boring_time(instant) As the number of rules is always finite, you can also make it a mapping. > > This seems like an obviously good idea to me, aside from potential > implementation difficulty and I'm not sure if there are backward > compatibility issues. > The backwards incompatibility is that PEP also want that ZonedDateTime [== datetime(tzinfo=tz("America/Chicago"))] does the sane thing and follows what NodaTime, JodaTime, etc. does - which is "Time line arithmetic". > So is there any more to be hashed out in the PEP (it seem where to get the > time zone data on Windows is one unresolved issue). > > Then there seem to be the big hang-up: people want a way to define Periods > (as defined above) and want to be able to do datetime math with them. I"m > still really confused as to why folks seemed to think "time zone aware" > somehow meant using Peiods rather than Durations for arithmetic, but there > you go. Clearly this is very useful thing to have, but it's NEW feature, and > not covered in the PEP. No, people want to keep adding Durations (timedelta) to ZonedDataTime and expect it to work in "time zone aware" manner. In particular adding 24h duration should add exactly 24h, *always*. This is *NOT* how Python's datetime currently works.

1 0

Datetime-SIG July 2015