[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Change by Paul Ganssle : -- pull_requests: +4721 ___ Python tracker ___ ___

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Changes by Alexander Belopolsky : -- resolution: -> fixed stage: test needed -> resolved status: open -> closed ___ Python tracker

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Alexander Belopolsky added the comment: New changeset 018d353c1c8c87767d2335cd884017c2ce12e045 by Alexander Belopolsky in branch 'master': Closes issue bpo-5288: Allow tzinfo objects with sub-minute offsets. (#2896)

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Alexander Belopolsky added the comment: > My concern is that it makes timestamp parsing more complex To the contrary. The timezone field can now be parsed the same way as the time field plus the sign. -- ___ Python tracker

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

STINNER Victor added the comment: > I did add a few lines of code to support subsecond formatting, but at some > point we should be able to unify timedelta and timezone formatting. My concern is that it makes timestamp parsing more complex because we would have to handle the theorical case of

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Alexander Belopolsky added the comment: Victor, Tim called for removal of all restrictions on the offsets. See msg248468. I left the range restriction intact because we have some algorithms that rely on that, but in general I agree with Tim. There is nothing to be gained from restricting

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

STINNER Victor added the comment: James Henstridge: > The Olson time zone database (used by most UNIX systems and Mac OS X) has a number of time zones with historic offsets that use second resolution (from before those locations switched to a rounded offset from GMT). Ok for increasing the

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Alexander Belopolsky added the comment: In PR 2896, I've modified %z formatting code to output sub-minute data if present. I think %z parsing should be also modified to accept sub-minute data, but I would like to do it in the context of issue 24954. Thoughts? --

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Changes by Alexander Belopolsky : -- assignee: -> belopolsky ___ Python tracker ___

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Alexander Belopolsky added the comment: Most of the code supporting arbitrary offsets has already been committed. The only part left was to remove the checks and implement printing. -- ___ Python tracker

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Changes by Alexander Belopolsky : -- pull_requests: +2949 ___ Python tracker ___

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Changes by Alexander Belopolsky : -- priority: low -> versions: +Python 3.7 -Python 3.5 ___ Python tracker ___

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Guido van Rossum added the comment: I haven't reviewed the code, but given Tim Peters' response (which matches my own gut feeling) we should just allow/support tz offsets with second-precision (and deal with the default formatting issues in a backwards compatible way, of course). Hope the

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Changes by Alexander Belopolsky : -- nosy: +gvanrossum ___ Python tracker ___

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Alexander Belopolsky added the comment: In my PEP 495 work (see issue 24773,) I relaxed the offset checks to allow any integer number of *seconds*. This was necessary to support all timezones in the Olson database. With respect to string representation of such offset, I would like to bring

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Tim Peters added the comment: The only reason for the restriction that I can think of is that some text representation of datetime only provide 4 digits for timezone. There never was a compelling reason. It was simply intended to help catch programming errors for a (at the time) brand new

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Changes by Alexander Belopolsky alexander.belopol...@gmail.com: -- assignee: belopolsky - versions: +Python 3.5 -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5288 ___

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Fergus Noble added the comment: GPS time doesn't include leap seconds so I think datetime is a good representation. If datetime doesn't know about leap seconds then there would still be some issues with finding the timedelta between a GPS time and a UTC time straddling a leap second but I

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Alexander Belopolsky added the comment: Is it practical to implement GPS time as datetime given that we don't have support for leap seconds? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5288

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Fergus Noble added the comment: Digging up an old issue but I am also interested in seeing this enhancement. Specifically to represent GPS time which is (currently) 16 seconds ahead of UTC. -- nosy: +Fergus.Noble ___ Python tracker

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Uploaded issue5288.diff to Rietveld: http://codereview.appspot.com/1698050 -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Alexander Belopolsky belopol...@users.sourceforge.net added the comment: issue5288a.diff addressed comments from Rietveld. -- stage: unit test needed - commit review Added file: http://bugs.python.org/file17897/issue5288a.diff ___ Python tracker

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Alexander Belopolsky belopol...@users.sourceforge.net added the comment: C code changes eliminating round-trips between timdelta and int offsets committed in r82642 and Python code changes committed to sandbox in r82641. Now the requested behavior change is easy and I am about +0.5 on relaxing

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Alexander Belopolsky belopol...@users.sourceforge.net added the comment: I am attaching a test coverage file for the patched datetimemodule.c. -- Added file: http://bugs.python.org/file17874/datetimemodule.c.gcov ___ Python tracker

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Alexander Belopolsky belopol...@users.sourceforge.net added the comment: It looks like I attached coverage for the original file. See new-datetimemodule.c.gcov for coverage after the change. -- Added file: http://bugs.python.org/file17875/new-datetimemodule.c.gcov

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Alexander Belopolsky belopol...@users.sourceforge.net added the comment: I am attaching a rough patch which removes timedelta - int minutes - timedelta round trips from utcoffset handling code. I think the result is an improvement, but needs more polishing. Mark, Do you think this is worth

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Changes by Alexander Belopolsky belopol...@users.sourceforge.net: -- keywords: +patch Added file: http://bugs.python.org/file17864/issue5288.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5288

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Changes by Alexander Belopolsky belopol...@users.sourceforge.net: Removed file: http://bugs.python.org/file17857/issue5288.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5288 ___

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Changes by Alexander Belopolsky belopol...@users.sourceforge.net: Added file: http://bugs.python.org/file17865/issue5288.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5288 ___

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Changes by Alexander Belopolsky belopol...@users.sourceforge.net: Removed file: http://bugs.python.org/file17864/issue5288.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5288 ___

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Alexander Belopolsky belopol...@users.sourceforge.net added the comment: I am attaching a patch against sandbox version of datetime.py. With this patch, there is a single place where subminute offset is rejected, _check_utc_offset() function. I have also added whole minute asserts in places

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Alexander Belopolsky belopol...@users.sourceforge.net added the comment: This proved to require a lot of changes to C implementation because most of timezone arithmetics is done using integer operations with offset in minutes. It is easy, however to do this in pure python implementation which

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Alexander Belopolsky belopol...@users.sourceforge.net added the comment: As far as I can tell, the TZ offset code can be simplified by eliminating conversion from timedelta to int and back in utcoffset() and dst() methods of time and datetime objects. The only reason for the restriction that

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

Changes by Alexander Belopolsky belopol...@users.sourceforge.net: -- assignee: - belopolsky nosy: +belopolsky stage: - unit test needed type: - feature request versions: +Python 3.2 -Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

New submission from James Henstridge ja...@jamesh.id.au: The datetime module does not support time zones whose offset from UTC is not an integer number of minutes. The Olson time zone database (used by most UNIX systems and Mac OS X) has a number of time zones with historic offsets that use