New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tzinfo.fromutc()
fails when used for a fold-aware tzinfo implementation
#72788
Comments
After PEP-495, the default value for non-fold-aware datetimes is that they return the DST side, not the STD side (as was the assumption before PEP-495). This invalidates an assumption made in dtdst = dt.dst()
if dtdst is None:
raise ValueError("fromutc() requires a non-None dst() result")
delta = dtoff - dtdst
if delta:
dt += delta
dtdst = dt.dst()
if dtdst is None:
raise ValueError("fromutc(): dt.dst gave inconsistent "
"results; cannot convert") Line 997 ( Line 997 in be8de92
If 997 is changed to: dtdst = dt.replace(fold=1).dst() That will not affect fold-naive zones (which are instructed to ignore the class FoldAwareTzInfo(datetime.tzinfo):
def fromutc(self, dt):
dt_wall = super(FoldAwareTzInfo, self).fromutc(dt)
is_fold = self._get_fold_status(dt, dt_wall)
|
I don't think timezones that satisfy the invariant expected by the default fromutc() is common enough that we need to provide special support for them. Note that in most cases it is the UTC to local conversion that is straightforward while Local to UTC is tricky, so the code that reduces a simple task to a harder one has questionable utility. |
Of the With current implementations In any case, I can't think of a single actual downside to this change - all it does is preserve the original behavior of |
Paul G at Github: """ For most of the tzinfo implementations I'm providing (tzrange, tzwin, etc), there's no problem with an invariant standard time offset, so I'd prefer to fall back on the default algorithm in those cases. Another advantage with using the standard algorithm as a starting point is that it all the type checking and such that's done in fromutc is done at that level, and I don't have to keep track of handling that. All that said, it's not a huge deal either way. Since it is not a big issue for you, I would rather not reopen this can of worms. It may be better to return a clearly erroneous result on fold-aware tzinfos to push the developers like you in the right direction. :-) After all, how much effort would it save for you in dateutil if you could reuse the base class fromutc? |
Realistically, this saves me nothing since I have to re-implement it anyway in in all versions <= Python 3.6 (basically just the exact same algorithm with line 997 replaced with enfold(dt, fold=1) rather than dt.replace(fold=1), but I'd rather it fall back to the standard That said, I don't see how it's a big can of worms to open. If you're going to provide |
You've got me on the fence here. If what you are saying is correct, it would make sense to make this change and better do it before 3.6 is out, but it would take me some effort to convince myself that an implementation that reuses patched fromutc() is indeed correct. Why don't you implement tzrange.fromutc() in terms of say tzrange.simple_fromutc() which is your own patched version of tzinfo.fromutc(). If this passes your tests and is simpler than a straightforward fromutc() that does not have to look at tzinfo through the needle hole of utcoffset()/dst() pair but knows the internals of your timezone object, we can consider promoting your simple_fromutc() to default stdlib implementation. Alternatively, you can just convince Tim. :-) |
So I created a little patch for this, and when I was working on it I realized that it's actually possible to implement full It adds a bit of overhead, but I think any current fold-aware operations need to be implemented in pure Python anyway (and involve even more overhead), so I think it would be a net gain. The big downside I see here is that it cannot take advantage of any sort of "is_ambiguous" function and has to rely on the method of "change the fold and see if the answer is different" to determine ambiguity. I think this is a small cost to pay for a generic implementation, though. I'm pretty busy this week and next week will be hectic too, but towards the end of the month I can probably come up with a test suite for this and look at some actual performance numbers. |
I am aware of that. In fact, some of the draft versions of PEP-495 implementation did contain such code. The problem is that any such tz.fromutc() implementation would necessarily change the behavior of the old programs. Moreover, any implementation of tz.fromutc() in terms of tz.utcoffset() is more complicated and less efficient than code that he's direct access to a database of transition times. |
This I'm not sure about - the implementation I've provided gives the same answer for any program that pays no attention to
While true, that does not argue in favor of having a version of Another argument in favor of having At the end of the day, almost everyone who cares about efficiency will use dateutil or pytz for their application, and dateutil and pytz can and do re-implement fromutc when appropriate - though there are still some |
Paul, In your opening post to this issue you suggested to change one line 1 in Lib/datetime.py from dtdst = dt.dst() to dtdst = dt.replace(fold=1).dst() This looks like a rather innocuous change, but it does not by itself make fromutc() return properly "enfolded" instances. IIRC, the best algorithm that Tim and I were able to come up with to derive the fold value required something like six utcoffset() probes. PR 7425 that you submitted looks somewhat involved. Can you submit an equivalent datetime.py patch? |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: