classification
Title: datetime.datetime.isoformat truncation problem
Type: behavior Stage: patch review
Components: Extension Modules Versions: Python 2.7, Python 2.6
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: amaury.forgeotdarc, eric.smith, exarkun
Priority: normal Keywords: needs review, patch

Created on 2009-12-01 02:02 by exarkun, last changed 2009-12-29 22:41 by amaury.forgeotdarc. This issue is now closed.

Files
File name Uploaded Description Edit
isoformat.patch amaury.forgeotdarc, 2009-12-01 08:31
isoformat-2.patch amaury.forgeotdarc, 2009-12-01 22:18
Messages (6)
msg95845 - (view) Author: Jean-Paul Calderone (exarkun) * (Python committer) Date: 2009-12-01 02:02
Passing NUL as the separator to isoformat drops the time part of the
result entirely:

>>> import datetime
>>> datetime.datetime.today().isoformat()
'2009-11-30T20:57:37.918750'
>>> datetime.datetime.today().isoformat('x')
'2009-11-30x20:57:39.902573'
>>> datetime.datetime.today().isoformat('\0')
'2009-11-30'
>>>
msg95850 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2009-12-01 08:31
Here is a test + fix.
msg95854 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2009-12-01 10:54
The patch looks okay to me, and works on 2.7. Although it's slightly out
of date with respect to line numbers, it still applies cleanly.

My trivial suggestions are that I'd replace:
x += PyOS_snprintf(buffer + 8, bufflen - 8, ".%06d", us);
with
x += PyOS_snprintf(buffer + x, bufflen - x, ".%06d", us);
in the extremely unlikely event that the time format string ever
changes. I'd probably also throw in an assert(bufflen >= x).

But these 2 points are nits.
msg95882 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2009-12-01 22:18
Here is a new patch against a fresh trunk, and with the suggested changes: 
they indeed make the code more consistent with other parts.
msg95883 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2009-12-01 22:43
I think you need to put an assert before the line with bufflen-x, since
that's the calculation you're trying to ensure doesn't underflow. And I
guess that technically you should inspect the result of PyOS_snprintf
for an error, but given that we know the buffer sizes it's not so important.

Other than that, looks good. Sorry for the piecemeal patch review.
msg97011 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2009-12-29 22:41
Fixed with r77122 (trunk) and r77125 (release26-maint).

py3k uses PyUnicode_FromFormat directly and does not have this problem.
I merged the test there nonetheless.
History
Date User Action Args
2009-12-29 22:41:45amaury.forgeotdarcsetstatus: open -> closed
resolution: fixed
messages: + msg97011
2009-12-01 22:43:55eric.smithsetmessages: + msg95883
2009-12-01 22:18:20amaury.forgeotdarcsetkeywords: + needs review
files: + isoformat-2.patch
messages: + msg95882
2009-12-01 10:54:59eric.smithsetpriority: normal

type: behavior
assignee: amaury.forgeotdarc ->
components: + Extension Modules
versions: + Python 2.6, Python 2.7
nosy: + eric.smith

messages: + msg95854
stage: patch review
2009-12-01 08:31:26amaury.forgeotdarcsetfiles: + isoformat.patch

nosy: + amaury.forgeotdarc
messages: + msg95850

assignee: amaury.forgeotdarc
keywords: + patch
2009-12-01 02:02:59exarkuncreate