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
time.utcoffset() #51911
Comments
The proposal to add the function that will allow to get current UTC offset. Do we need a PEP for this one? def time.utcoffset(): |
I think this would be nice, but see msg97471 from your diff.py ISO timestamp issue. time.daylight should probably be time.localtime().tm_isdst. |
Updated Python code according to discussion from aforementioned issue bpo-7582. Unfortunately, I can't find Python source for def time.utcoffset(): |
The (and I agree that anything making the time stuff easier to use is welcome) |
I would prefer exposing tm_gmtoff in time.localtime() output. The advantage is that on platforms that support it is struct tm, it will return correct offset for times in the past, not only for the current time. See bpo-1647654. On platforms without tm_gmtoff we can fill it with -tm_isdst?timezone:altzone. The current situation on Linux is just backwards: we are trying to divine altzone by sampling tm_gmtoff and throw tm_gmtoff away. See http://blogs.gnome.org/jamesh/2006/12/31/python-timetimezone-timealtzone-edge-case/. |
I am going to close this as superseded by bpo-9527. All these issues, current, bpo-9527, and bpo-1647654 are really about Python's lack of access to the system timezone information and bpo-9527 seem to be the most appropriate solution. My specific concern about proposed time.utcoffset() is that you normally need UTC offset together with current time, but localtime() call followed by utcoffset() may lead to a race condition. |
This one is a different issue. Even though it can not be solved without by bpo-9527, it is not superseded by it. So, better add to dependencies. |
You can discuss within the comments whether this issue should be re-opened or not, but do not take it upon yourself to change the status on your own once a core developer has already closed an issue as their decision supersedes that of a regular user. |
I am tired. Do as you wish. |
Just to clarify: Anatoly changed the resolution, not status (and I agree that was not appropriate.) The status was set to "pending" and that would change to "open" automatically if a new comment is posted. As for the substance of Anatoly's objection - I agree that this proposal is different from bpo-9527. That is why I set resolution to "rejected" rathe than "duplicate". This issue can probably be properly classified as a duplicate of bpo-1647654, but I consider bpo-9527 the most promising solution to the problem of finding the system timezone offset. |
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: