Mailman 3 July 2015 - Datetime-SIG

Timezone database
by Felipe Ochoa 29 Jul '15

29 Jul '15

[Branching from The BDFL's take] There are a few additional issues which I'm not sure are included in this > discussion or not: > - A unified API for accessing an up-to-date timezone database. This has > been discussed in the past, and we couldn't find a solution that satisfied > all requirements (the main problem being different platform expectations > IIRC), but it's probably worth it trying again. The current solution proposed in the PEP is to have platforms with /usr/share/zoneinfo use that as long as they want. For other platforms Python would ship with a built-in copy (roughly speaking) of the database. There would then be separate tzdata-update package on pypi that can be `pip install`ed to update the timezone database whenever the user feels the need to do so (because /usr/share/zoneinfo is no longer receiving updates or because it doesn't exist) What are the unsatisfied requirements of this design?

1 0

Re: [Datetime-SIG] What's are the issues?
by Tim Peters 29 Jul '15

29 Jul '15

[TIm] >> Nope, that's mistaken on both counts, but it is technical. What I >> said is correct in all respects given the current code. [:Lennart] > That the current code works as designed is not really the issue we > discuss here, though. > > And then you start discussing conversions, which wasn't the issue, it > was arithmetic. Lennart, you replied to a quote from me which was specifically and only talking about timezone conversions. Here it is, the only part you quoted: > But, as the docs have always pointed out, it (specifically .fromutc(), > which is at the base of all relevant calculations) doesn't even try to > handle transitions due to _other_ causes. The only other such cause > I'm aware of is when a timezone's _base_ offset from UTC changes (not > a temporary DST transition, the timezone's "standard" offset changes > permanently (meaning until someone decides to change it again)). Now you chide me with "And then you start discussing conversions, which wasn't the issue, it was arithmetic"?! The quote you were replying to was _entirely_ about conversions, and nothing whatsoever about arithmetic. Silly me - I thought you were asking about DST conversions and base-offset-changing conversions. And just because that was the topic you were commenting on ;-) Here's you. talking about conversion when the base UTC offset changes: > This will be handled in the exact same way as DST changes, and if > this is incorrect, then reasonably, so is the DST handling. > What is "incorrect" here is of course a matter of opinion. That's wholly consistent with the belief that you were staying on the original topic (conversion). Then you continued, I _guess_ talking about arithmetic, because you weren't explicit and it really had nothing to do with the paragraph just ended: > I think it's incorrect because it doesn't agree with reality, you have > claimed that it is correct, in "as per design". You weren't explicit about what "it" and "it's" referred to. I charitably tried to assume you weren't trying to change the current topic (which _was_ conversions, and obviously so)., so replied at length about how arithmetic and conversions were distinct issues. Finally, > But then reasonably that goes for this case as well? The same thing > happens, which is that depending on the transitions direction, you can > either end up in a time that doesn't exist, or one that happens twice. Which seemed to be bouncing back to the original topic. Or not. Since you seem to believe _I_ was changing the topic, my best guess now is that, without saying anything explicit about it, in your _head_ you weren't thinking about conversions at all, but instead about what happens when doing _arithmetic_ at times near timezone transition points. If so, I plead guilty to a failure of telepathy ;-) But the quote you responded to at first wasn't about arithmetic. It was about conversions. In its original context that was dead obvious. But even stripped of context, it still explicitly talks about .fromutc(). A conversion method. Not arithmetic.

1 0

Re: [Datetime-SIG] The BDFL's take
by Alexander Belopolsky 29 Jul '15

29 Jul '15

On Wed, Jul 29, 2015 at 12:08 PM, Lennart Regebro <regebro(a)gmail.com> wrote: >>>> t = datetime.strptime("2014-11-02T01:30-0400", "%Y-%m-%dT%H:%M%z") > ValueError: 'z' is a bad directive in format '%Y-%m-%dT%H:%M%z' > > Nope, didn't work. Sorry, but it does work for me: $ TZ=America/New_York python3 Python 3.4.3 (default, Jul 20 2015, 12:59:38) [GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from datetime import * >>> t = datetime.strptime("2014-11-02T01:30-0400", "%Y-%m-%dT%H:%M%z") which version of Python are you using?

1 0

is_dst flag
by Felipe Ochoa 29 Jul '15

29 Jul '15

In the hopes of separating the discussion into the various sub-issues, here's what I think is the status on the is_dst flag. (Guido) From '[Datetime-SIG] The BDFL's take' > - An "is_dst" flag for datetime objects. Again, this should default to > "backwards compatible" (== "don't care", the -1 value in struct tm) so that > pickles are two-way compatible with Python 3.5 and before. The key thing here is that the flag is **on the datetime object**, (in addition, timezone objects can keep track of whatever they internally need). This flag is only necessary for local times with a timezone that can occur twice. The typical use-case is, e.g., 1.30am on the day that clocks turn back for DST in the US. `datetime(2002, 10, 27, 1, 30, 0, tzinfo=zoneinfo('America/New_York')` is ambiguous, and the point of the is_dst flag is to determine which of the two possible moments the datetime refers to. Note that the ambiguity is only a factor when converting to another timezone (or a unix timestamp). Sidenote: Per earlier discussion, this flag should probably have a different name to clarify that it only applies in ambiguous cases, and is not just a DST problem (For another example, see the pytz docs <http://pytz.sourceforge.net/#problems-with-localtime> and search for Warsaw).

1 0

Re: [Datetime-SIG] The BDFL's take
by Lennart Regebro 29 Jul '15

29 Jul '15

On Wed, Jul 29, 2015 at 5:50 PM, Alexander Belopolsky <alexander.belopolsky(a)gmail.com> wrote: > What do you see lacking in this solution? Btw: I pasted examples of the problems. That you can work around those in various ways do not change the fact that those problems remain. Do you have question about those examples? //Lennart

1 0

Re: [Datetime-SIG] The BDFL's take
by Lennart Regebro 29 Jul '15

29 Jul '15

On Wed, Jul 29, 2015 at 5:50 PM, Alexander Belopolsky <alexander.belopolsky(a)gmail.com> wrote: > The problems you gave, are perfectly solvable using current Python 3 standard > library. No, it isn't, as the Python 3 standard library does not contain real-life timezone implementations. > For some reason you insist on solving them using third party > tools that are not designed for those particular tasks. The third party tool is designed to handle real-life timezone implementations, and implements them precisely the way the datetime designers intented. It does exactly what Tim says it should do. > You want to know what was the local time in New York one astronomical hour > after 2014-11-02T01:30-0400 - set TZ=America/New_York and do this: > >>>> t = datetime.strptime("2014-11-02T01:30-0400", "%Y-%m-%dT%H:%M%z") >>>> u = (t+timedelta(hours=1)) >>>> u.astimezone().strftime("%Y-%m-%dT%H:%M%z") > '2014-11-02T01:30-0500' >>> t = datetime.strptime("2014-11-02T01:30-0400", "%Y-%m-%dT%H:%M%z") ValueError: 'z' is a bad directive in format '%Y-%m-%dT%H:%M%z' Nope, didn't work. Did you mean uppercase Z? >>> t = datetime.strptime("2014-11-02T01:30-0400", "%Y-%m-%dT%H:%M%Z") ValueError: time data '2014-11-02T01:30-0400' does not match format '%Y-%m-%dT%H:%M%Z' Probably, but it still didn't work. > What do you see lacking in this solution? Please test your examples before you paste them, I have no idea what you are trying to do.

1 0

Re: [Datetime-SIG] The BDFL's take
by Alexander Belopolsky 29 Jul '15

29 Jul '15

On Wed, Jul 29, 2015 at 11:53 AM, Łukasz Rekucki <lrekucki(a)gmail.com> wrote: > The cheat here is that you call "astimezone()" without arguments, thus > it will *always* convert to UTC and back internally (even if your OS > timezone did not change a single bit). This is not a "cheat." This is a documented and the recommended way to accomplish this task. > If you pass TZ explicitly, it doesn't work. Sure and there are an infinite number of other ways to make a mistake in date/time calculations.

1 0

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

29 Jul '15

Sent from my iPhone Chris Barker chris.barker at noaa.gov What are the issues still to be resolved? [with the PEP] The is_dst flags added are not implementable, as they aim to make it possible to do correct timezone conversions, and Guido and Tim have declared that they don't want that, but that they want to keep the arithmetic what they call "naive Huh? Now I'm really confused. IIUC, the is_dst flag is required in order to be able to round-trip between UTC and local_time representations. In particular, so the API can support specifying a datetime in a time zone that "happens" twice without ambiguity. But this is required whether or not you want to support what I'm calling Calendar operations. Also, the PEP is about adding useful tzinfo objects to the stdlib, yes? I agree that tzinfo objects are much less useful without a is_dst flag, but that is orthogonal to how tzinfo objects work. Guido and Tim have declared that they don't want that, but that they want to keep the arithmetic what they call "naive This is why I've been harping on semantics. Apparently I've totally misunderstood Tim's points ( or you have ;-) ). As it stands today, time arithmetic such as: A_datetime + timedelta( days=1) Means: return a datetime object that represents a point on the time continuum 24 hours further on. There is no reason that has to change one bit in order to support time zones "properly". All a timezone is is a set of rules for how to map from a point on the time continuum to our human-friendly, politically and astronomically driven "calendar" representation. Doing that correctly is really useful in an of itself. You are interpreting Tim's "naive time arithmetic" differently than I have ( though his last note did confuse me, and did fit your interpretation), so I'll try to re-phrase: The datetime module does, and will always define: A_datetime + timedelta( days=1) To mean *BOTH*: "Move along the time continuum 24 hours." And "Move to the same clock time of the next calendar day" I find this hard to believe, because that can only be true for naive datetime a, or timezones with no DST and no change of definition. (I.e. UTC). And yet, the original implementation did provide a hook for a tzinfo object. Was it never intended to be useful???? BTW, as Tim pointed out (and I at least found it interesting), that datetime, while encoding the location on the time continuum in calendar units ( year, month, day, ....), when doing operations, it is essentially working in "microseconds since year 1". Which, indeed, is what you need to do to do time arithmetic rationally. I'll send in a patch to withdraw PEP-431 it later today, I hope. Sigh. Just saw the PEP update. Yes, doing calculations in UTC is the best way to go -- using an encoding that is not continuous for arithmetic would be a nightmare. Sorry to be late to the party, but I'll take your word for it that doing the to-from UTC conversion would be difficult with the current implementation. -Chris //Lennart _______________________________________________ Datetime-SIG mailing list Datetime-SIG(a)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/

2 1

Re: [Datetime-SIG] The BDFL's take
by Łukasz Rekucki 29 Jul '15

29 Jul '15

On 29 July 2015 at 17:18, Alexander Belopolsky <alexander.belopolsky(a)gmail.com> wrote: > On Wed, Jul 29, 2015 at 10:49 AM, Lennart Regebro <regebro(a)gmail.com> wrote: >> I disagree with that. To make "non-human" (ie correct) calculations I >> have to first convert the timezone to UTC, then do the calculations, >> then convert it back. > > You snipped my example and I won't repeat it for the umpteen time, but > it did not involve converting the timezone to UTC at all. Corrected example (with 11 as month): >>> t = datetime(2014, 11, 1, 17, tzinfo=timezone.utc).astimezone() >>> t.strftime('%c %Z %z') '11/01/14 18:00:00 Central European Standard Time +0100' >>> u = t + timedelta(1) >>> u.astimezone().strftime('%c %Z %z') '11/02/14 17:00:00 Central European Standard Time +0000' The cheat here is that you call "astimezone()" without arguments, thus it will *always* convert to UTC and back internally (even if your OS timezone did not change a single bit). If you pass TZ explicitly, it doesn't work: >>> t = datetime(2014, 11, 1, 17, tzinfo=timezone.utc).astimezone() >>> t.strftime('%c %Z %z') '11/01/14 18:00:00 Central European Standard Time +0100' >>> zone = t.tzinfo >>> u = t + timedelta(1) >>> u = u.astimezone(zone) >>> u.strftime('%c %Z %z') '11/02/14 18:00:00 Central European Standard Time +0100' BR, Łukasz Rekucki

1 0

Re: [Datetime-SIG] The BDFL's take
by Alexander Belopolsky 29 Jul '15

29 Jul '15

On Wed, Jul 29, 2015 at 11:33 AM, Lennart Regebro <regebro(a)gmail.com> wrote: > On Wed, Jul 29, 2015 at 5:18 PM, Alexander Belopolsky > <alexander.belopolsky(a)gmail.com> wrote: >> You snipped my example and I won't repeat it for the umpteen time, but >> it did not involve converting the timezone to UTC at all. > > You asked for examples of problem, I gave you two example of problems. The problems you gave, are perfectly solvable using current Python 3 standard library. For some reason you insist on solving them using third party tools that are not designed for those particular tasks. You want to know what was the local time in New York one astronomical hour after 2014-11-02T01:30-0400 - set TZ=America/New_York and do this: >>> t = datetime.strptime("2014-11-02T01:30-0400", "%Y-%m-%dT%H:%M%z") >>> u = (t+timedelta(hours=1)) >>> u.astimezone().strftime("%Y-%m-%dT%H:%M%z") '2014-11-02T01:30-0500' What do you see lacking in this solution? The only thing I see worth improving is adding support for more than one local timezone so that I could ask for >>> u.astimezone('Australia/Melbourne') without having to switch my global TZ settings.

1 0