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

[Paul Ganssle]

Change by Paul Ganssle :


--
pull_requests: +4721

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
resolution:  -> fixed
stage: test needed -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

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)
https://github.com/python/cpython/commit/018d353c1c8c87767d2335cd884017c2ce12e045


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

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 timezone with microsecond precision.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

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 the offsets.  It is just some extra code to enforce gratuitous 
limitations.

Note that Olson's database limits its precision to seconds for historical 
reasons.  The mean solar time offsets that they record are known to subsecond 
precision.

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

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 resolution to seconds. But PR 2896 increases the 
resolution to microseconds. What is the rationale for supporting microseconds?

I would prefer to only accept microseconds=0.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

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?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
assignee:  -> belopolsky

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
pull_requests: +2949

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
priority: low -> 
versions: +Python 3.7 -Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Guido van Rossum]

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 patches aren't too stale -- good luck moving them to GitHub!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
nosy: +gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

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 up 
issue 24954.  We don't even have support for printing regular offsets in ISO 
format.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Tim Peters]

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 feature, and one where no 
concrete timezone support was supplied at first.  Lots of people were writing 
their own tzinfo subclasses, and nobody at the time was, e.g., volunteering to 
wrap the Olson database.

I'm in favor of removing all restrictions on offsets.  Speed is of minor 
concern here - if it simplifies the code to delegate all offset arithmetic to 
classic datetime +/- timedelta operations, fine.

String representations are a mess.  If some popular standard doesn't cater to 
sub-minute (or sub-second!) offsets, fine, make up a format consistent with 
what such a standard would have defined had it addressed the issue, and 
document that if a programmer picks a timezone whose offsets go beyond what 
that standard supports, tough luck.  Then Python will give something sensible 
Python can live with, but won't try to hide that what they're doing does in 
fact go beyond what the standard supports.

--
nosy: +tim.peters

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5288
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Fergus Noble]

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 guess a similar issue also exists with two 
UTC times.

For my application all the times I am dealing with are in a short period and 
will have the same UTC offset so its a little easier, I can probably avoid most 
of these issues.

However, wouldn't it be possible to implement the general case with a 
non-constant utcoffset function (and new fromutc implementation) in the tzinfo 
class? Of course there is no way to properly handle UTC times more than 6 
months or so in the future...

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5288
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Fergus Noble]

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 rep...@bugs.python.org
http://bugs.python.org/issue5288
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

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
http://bugs.python.org/issue5288
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

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 rep...@bugs.python.org
http://bugs.python.org/issue5288
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

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 the 
offset checks to allow seconds in the offsets and about +0.1 on removing the 
checks altogether and allowing arbitrary timedeltas even over 1 day.

The only substantive question in my mind is how to handle printing in formats 
like %z which only provide 4 digits for UTC offset.  Two options seem 
reasonable: a) truncate sub-minute offsets; and b) follow RFC 3339 
recommendation and translate the time into the nearest whole-minute timezone.

I am slightly is favor of (a), but this whole problem may be a reason to reject 
this RFE.

--
keywords: +easy -patch
priority: normal - low
stage: commit review - unit test needed

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5288
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

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 rep...@bugs.python.org
http://bugs.python.org/issue5288
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

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

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5288
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

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 pursuing?  I am not intending to add support for 
sub-minute offsets yet, just pass offsets around as timedeltas internally 
without unnecessary conversions to int and back.

--
keywords:  -easy, patch
nosy: +mark.dickinson
Added file: http://bugs.python.org/file17857/issue5288.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5288
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

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
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

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 where sub-minute part of the offset is discarded or assumed 0.

--
keywords: +patch
Added file: http://bugs.python.org/file17844/issue5288-proto.diff

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5288
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

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 can be found 
at 
http://svn.python.org/view/*checkout*/sandbox/branches/py3k-datetime/datetime.py
 .

Marking this easy to attract volunteers who may want to do Python prototype.

--
keywords: +easy
nosy: +haypo

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5288
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

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 I can think of is that some text 
representation of datetime only provide 4 digits for timezone. The behavior of 
formatting functions, can be preserved while allowing fractional minute offsets 
elsewhere.

On the other hand, given that this issue did not see a single response in more 
than a year, it seems that there is little interest in fixing it.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5288
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

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
http://bugs.python.org/issue5288
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[James Henstridge]

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 second
resolution (from before those locations switched to a rounded offset
from GMT).

If you are working purely with the Python date time module, you can
round these offsets to whole numbers of minutes and get consistent
results (this is what the pytz module does), there are problems if you
want to interact with other programs using the Olson database.

As an example, PostgreSQL can return dates with sub-minute UTC offsets
and it would be nice to be able to represent them exactly.

The documentation doesn't explain why offsets need to be a whole number
of minutes, and the interface (returning timedeltas) doesn't look like
it'd need changing to support second offsets.  I wouldn't expect any
more complexity in the code to support them either.

--
components: Extension Modules
messages: 82299
nosy: jamesh
severity: normal
status: open
title: tzinfo objects with sub-minute offsets are not supported (e.g. 
UTC+05:53:28)
versions: Python 2.7, Python 3.1

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5288
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com