This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Add datetime.time.strptime and
Type: enhancement Stage: patch review
Components: Extension Modules Versions: Python 3.8
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Juarez.Bochi, Julian.Gindi, adam-collard, ajaksu2, alanvgreen, amaury.forgeotdarc, belopolsky, berker.peksag, cvrebert, guettli, jafo, josh-sf, maciej.szulik, matheus.v.portela, matrixise, p-ganssle, petre, sonderblade, tiktuk, vajrasky, vstinner, westley.martinez
Priority: Keywords: needs review, patch

Created on 2005-01-12 14:53 by josh-sf, last changed 2022-04-11 14:56 by admin.

File name Uploaded Description Edit
strptime.diff josh-sf, 2005-01-12 14:54
strptime2.diff josh-sf, 2005-02-02 22:00 time.strptime and date.strptime as well
date-strptime.patch amaury.forgeotdarc, 2009-06-23 23:18
issue1100942.diff belopolsky, 2010-06-09 15:17
issue1100942_pure.diff Juarez.Bochi, 2012-07-20 09:19 review
issue1100942_pure2.diff Juarez.Bochi, 2012-07-20 14:18 review
issue1100942_v4.diff berker.peksag, 2013-02-18 19:25 review
issue1100942_full.patch maciej.szulik, 2013-12-20 23:28 Full (merged) patch against current HEAD review
issue1100942_20140409.patch maciej.szulik, 2014-04-09 20:05 Patch fixed against current default branch review
issue1100942.patch maciej.szulik, 2015-05-11 21:23 review
issue1100942-3.6.patch matrixise, 2016-08-08 07:11 review
issue1100942_20170722.patch matheus.v.portela, 2017-07-22 08:03
Pull Requests
URL Status Linked Edit
PR 5578 open matrixise, 2018-02-07 10:28
Messages (48)
msg47516 - (view) Author: Josh (josh-sf) Date: 2005-01-12 14:53
Alllow creating new datetime objects by parsing date

datetime already has strftime, so adding strptime is

The new constructor is equivalent to
datetime(*(time.strptime(date_string, format)[0:6])).

Patch includes documentation and unit test.
msg47517 - (view) Author: Alan Green (alanvgreen) Date: 2005-01-25 12:05
Logged In: YES 

This patch will be welcomed by all of that have had to write
"datetime(*(time.strptime(date_string, format)[0:6]))".

I don't understand the C API well enough to check if
reference counts are handled properly, but otherwise the
implementation looks straight forward.

Documentation looks good and the test passes on my machine.

Two suggestions:

1. In the time module, the strptime() function's format
parameter is  optional. For consistency's sake, I'd expect
datetime.strptime()'s format parameter also to be optional.
(On the other hand, the default value for the format is not
very useful.)

2. Since strftime is supported by datetime.time, and datetime.datetime, I'd also expect
strptime to be supported by all three classes. Could you add
that now, or would it be better to do it as a separate patch?
msg47518 - (view) Author: Josh (josh-sf) Date: 2005-02-02 00:50
Logged In: YES 

Regarding support by datetime.time and, if a
date component or a time component is specified,
respectively, do you think that we should raise an
exception? or should we just ignore it?
msg47519 - (view) Author: Josh (josh-sf) Date: 2005-02-17 17:15
Logged In: YES 

The first patch has been applied, now just the second needs
to be. (strptime2.diff).

That adds support for date and time as well as datetime, as
per alanvgreen's suggestion.
msg47520 - (view) Author: Björn Lindqvist (sonderblade) Date: 2007-06-05 20:44
The patch doesn't apply cleanly anymore, although that was easy to fix. With the patch, I also get a few implicit declaration warnings and a few conflicting type errors. Rearranging the order of the functions solve that. Fixing that makes the code compile. The two new methods seem to work correct, although there should be unit tests.
msg82109 - (view) Author: Daniel Diniz (ajaksu2) * (Python triager) Date: 2009-02-14 19:08
Patch needs updating.
msg89650 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2009-06-23 23:18
Here is an updated patch, with tests.

The only thing that bugs me is the name of the method: date.strptime() 
seems a bit odd, given that it cannot accept a time part...
OTOH 'strptime' refers to the format specification: %Y-%m-%d
msg103731 - (view) Author: Alexander Belopolsky (Alexander.Belopolsky) Date: 2010-04-20 16:02
I am +1 for adding these features and I have only one comment on the code:

It is documented in time.strptime() documentation that
The default values used to fill in any missing data when more accurate values cannot be inferred are (1900, 1, 1, 0, 0, 0, 0, 1, -1). 

and "datetime.strptime(date_string, format) is equivalent to datetime(*(time.strptime(date_string, format)[0:6]))." according to datetime module documentation.

Thus, datetime.strptime("", "") returning datetime.datetime(1900, 1, 1, 0, 0) is not an implementation detail and there is no need to compute it in time_strptime.
msg103732 - (view) Author: Alexander Belopolsky (Alexander.Belopolsky) Date: 2010-04-20 16:12
BTW, it does not bother me that "date.strptime() 
seems a bit odd, given that it cannot accept a time part."  To me "time" in strptime means time specification that may include date, time or even just month.  If parsed specification does not fit in date (includes time component), date.strptime fails.  There is nothing wrong with it.  An alternative would be to make {date,time}.strptime() promiscuous and just drop unneeded components, but that would make these functions less useful because such behavior is simply datetime.strptime(..).{date,time}().
msg106805 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-05-31 19:23
Does this need to be brought up on python-dev for acceptance?
msg106807 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-05-31 19:45
This doesn't appear to be at all controversial;  I don't think it's necessary to consult python-dev.  (I haven't looked at the patch, though.)
msg107402 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-06-09 15:17
I have updated Amaury's patch for py3k.  I simplified the test for default date values and fixed a documentation nit. (Time fileds are [4:7], not [4:6]).  The result is attached as issue1100942.diff.

Note that date.strptime accepts some time specs and time.strptime accepts some date specs:

>>> time.strptime('1900', '%Y')
datetime.time(0, 0)
>>> date.strptime('00', '%H'), 1, 1)

This matches the proposed documentation, but I am not sure is desirable.  
I am about +0 for making the test more robust by scanning the format string and rejecting date format codes in time.strptime and time format codes in date.  This will also allow better diagnostic messages.  For example, instead of 

>>> date.strptime('01', '%M')
Traceback (most recent call last):
ValueError: date.strptime value cannot have a time part

we can produce "'%M' is not valid in date format specification."
msg114247 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2010-08-18 16:39
Is anyone still interested in moving this forward?
msg126013 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2011-01-11 15:43
New patch needed to address the issue of time.strftime() accepting %Y when year is 1900 and other similar oddities.  See msg107402 above.  Also a patch for is needed.
msg162732 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2012-06-13 21:44
Bumping priority to get this in before beta.
msg165882 - (view) Author: Juarez Bochi (Juarez.Bochi) Date: 2012-07-19 22:00
I have updated the patches since they were not applying cleanly and included a pure Python implementation that was missing.

It has the same issues that were mentioned on msg107402.

Do you have any suggestions? I'm planning to block the formats that are not allowed and raise Exceptions like suggested before:

>>> date.strptime('01', '%M')
"'%M' is not valid in date format specification."
msg165905 - (view) Author: Juarez Bochi (Juarez.Bochi) Date: 2012-07-20 09:09
I've updated my patch with the tests for datetime.time.strptime that were missing and also its pure Python implementation.

The previous diff also had some issues that I've fixed now: duplicated datetime.strptime method definition in c and the pure python docstring state that date.strpdate was a method and not a constructor.
msg165906 - (view) Author: Juarez Bochi (Juarez.Bochi) Date: 2012-07-20 09:19
Sorry. I updated my patch again to fix the exception message for time.strptime in the pure Python version.
msg165929 - (view) Author: Juarez Bochi (Juarez.Bochi) Date: 2012-07-20 14:18
I've updated the patch based on ezio.melotti and berkerpeksag reviews (thanks).

It's still missing the modifications proposed on msg107402.
msg174743 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2012-11-04 02:46
Could someone please review this with a view to getting the patch into the 3.4 code base, thanks.
msg174746 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2012-11-04 03:01

Are you planning to implement format validation as you described in msg165882?  Without that, date.strptime() is not very useful because it is almost equivalent to datetime.strptime().date().
msg182336 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2013-02-18 19:25
New patch attached.


* Addressed msg107402. I will update the C code if this implementation
  is correct.
* Added more tests
* Converted classmethods to staticmethods
* Removed doctests
* Updated documentation
msg184577 - (view) Author: Sean Reifschneider (jafo) * (Python committer) Date: 2013-03-19 01:08
I've tried to test this but v4 doesn't apply cleanly after pure2 is applied, and v4 doesn't include enough to test it (applying v4 only causes test failures).

I reviewed v4 and it looks fine in general.  I do see that there are changes in it unrelated to this issue, but they are PEP8 changes so I'm not objecting, but ideally that would be split out into a separate patch.

I think that this code will incorrectly detect something like '%s %%wall clock' as a date spec because it contains '%w', but strptime would consider that '%' followed by the string 'wall'.  A subtle edge case, but worth considering.  Maybe it needs to strip out %% first then look for the % sequences?  Or perhaps just do the conversion and if the Y/M/D fields are set in then decide that it included a date spec, or if the HMS are set then say that it has the time spec included?
msg206495 - (view) Author: Julian Gindi (Julian.Gindi) * Date: 2013-12-18 05:05
I'm interested in taking over and finishing whatever needs to be completed to move this forward. What else needs to be done? It looks like improved tests are needed, but are there any changes needed to the implementation code?
msg206498 - (view) Author: Vajrasky Kok (vajrasky) * Date: 2013-12-18 06:24
Julian, You need to update the patch from Juarez Bochi and Berker Peksag to the tip.
msg206500 - (view) Author: Maciej Szulik (maciej.szulik) * (Python triager) Date: 2013-12-18 07:54
Julian I'm almost done with this issue. I just need to polish that a little bit and I'll provide working patch withing few hours. Sorry for not writing about that later, but I'm just starting with this and I had some time figuring it out.
msg206519 - (view) Author: Julian Gindi (Julian.Gindi) * Date: 2013-12-18 14:17
Maciej, cool! I just wanted to move this patch forward because A) it seemed inactive and B) I would love to see this feature make it in :) I guess that means there is nothing that I need to do. Looking forward to this one, good work!
msg206717 - (view) Author: Maciej Szulik (maciej.szulik) * (Python triager) Date: 2013-12-20 23:28
I'm attaching merged and fixed patch (issue1100942_full.patch). Though during testing I found one issue with the patch: during checking for time part in date class I'm using (in _datetimemodule.c->date_strptime) DATE_GET_HOUR etc, but when given time parts are 0's then the test fails. Should I leave the patch as is, because possibility for 0's is very low or should I check the format string for time parts existence? Any further advice is appreciated.
msg215472 - (view) Author: Maciej Szulik (maciej.szulik) * (Python triager) Date: 2014-04-03 21:39
I've just checked the patch still applies to current HEAD. What about the question regarding 0's in date.strptime(...) I asked in previous comment? I'd like to move this issue forward now when 3.4 is released.
msg215474 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2014-04-03 21:53
Is this documentation still valid?

+.. staticmethod:: date.strptime(date_string, format)
+   Return a :class:`date` corresponding to *date_string*, parsed according to
+   *format*.  This is equivalent to ``date(*(time.strptime(date_string,
+   format)[0:3]))``.

I understand that the latest patch includes checking for time fields in date format.
msg215491 - (view) Author: Maciej Szulik (maciej.szulik) * (Python triager) Date: 2014-04-04 05:45
Alexander yes it's correct. It's checking for time part in date.strptime and for time part in time.strptime. The only problem I came into is that when passing 0 hours or 0 minutes into date.strptime it won't raise an exception, though doc explicitly says: "(...) ValueError is raised if the date string (...) the time part is nonzero". So I'm not sure whether this is enough or should I add additional checks if time part was set?
msg215537 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2014-04-04 17:11
If, format) validates format, then it is *not* equivalent to date(*(time.strptime(date_string, format)[0:3])), is it?
msg215559 - (view) Author: Maciej Szulik (maciej.szulik) * (Python triager) Date: 2014-04-04 19:40
You're right, I'll change this description removing 'This is equivalent...' sentence from description. I guess the same applies to 
time.strptime as well.
msg215843 - (view) Author: Maciej Szulik (maciej.szulik) * (Python triager) Date: 2014-04-09 20:05
Sorry it took me that long - but I'm finally attaching fixed patch. I've also checked it again current default branch and updated descriptions accordingly.
msg242569 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2015-05-04 18:56
@Alexander as the datetime expert could you get this committed in time for 3.5?
msg242803 - (view) Author: Maciej Szulik (maciej.szulik) * (Python triager) Date: 2015-05-09 09:51
I've just double checked, this patch applies cleanly to latest tip. I wouldn't mind having this reviewed and merged.
msg242809 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2015-05-09 12:33
datetime.strptime is a classmethod, but the new date.strptime and time.strptime methods are staticmethods. I think we should make the new methods classmethods too.
msg242917 - (view) Author: Maciej Szulik (maciej.szulik) * (Python triager) Date: 2015-05-11 21:23
Berker per your comment updated patch changing those two new methods (namely date.strptime and time.strptime) to be classmethod and not staticmethods.
msg272149 - (view) Author: Stéphane Wirtel (matrixise) * (Python committer) Date: 2016-08-08 07:11
Here is an updated version (for 3.6) of the patch of maciej.szulik.

I have executed all the tests.

Please, could you review this patch.

Thank you
msg273568 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-08-24 14:24
This does not look right: 

+.. classmethod:: time.strptime(date_string, format)
+   Return a :class:`time` corresponding to *date_string, parsed according to
+   *format*. :exc:`ValueError` is raised if the date string and format can't be
+   parsed by `time.strptime`, if it returns a value which isn't a time tuple,
+   or if the time part is nonzero.
msg279331 - (view) Author: Stéphane Wirtel (matrixise) * (Python committer) Date: 2016-10-24 19:19
belopolsky, could you tell me what it is wrong with the doc about time.strptime ?
msg279333 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-10-24 19:30
Shouldn't "time part" underlined in my previous note be "date part" instead?  Also, does non-zero mean non-empty?
msg279334 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2016-10-24 19:31
Never mind the second question.
msg298841 - (view) Author: Matheus Vieira Portela (matheus.v.portela) * Date: 2017-07-22 08:03
The patch is broken against Python 3.7. I'll try working on it.
msg298842 - (view) Author: Matheus Vieira Portela (matheus.v.portela) * Date: 2017-07-22 08:04
Also, may I move this issue to a GitHub PR?
msg311783 - (view) Author: Stéphane Wirtel (matrixise) * (Python committer) Date: 2018-02-07 10:41
I have updated the patch for 3.8, create a PR and fixed the documentation of _strptime._strptime, because this function returns a 3-tuple and not a 2-tuple as indicated in its comment. 

Thank you
msg313948 - (view) Author: Stéphane Wirtel (matrixise) * (Python committer) Date: 2018-03-16 13:34
Hello, just a small reminder for this issue and the PR ;-) when you have time
msg321550 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-07-12 13:37
I removed the easy keyword from this issue: it's open since 2005, it has 12 patches and 1 PR attached, and a lot of discussion.
Date User Action Args
2022-04-11 14:56:09adminsetgithub: 41431
2018-08-20 19:46:06p-gansslesetnosy: + p-ganssle
2018-07-28 12:21:01steve.dowersetkeywords: - easy
2018-07-12 13:37:59vstinnersetnosy: + vstinner
messages: + msg321550
2018-03-16 13:34:39matrixisesetmessages: + msg313948
2018-02-07 10:41:02matrixisesetmessages: + msg311783
versions: + Python 3.8, - Python 3.7
2018-02-07 10:28:08matrixisesetpull_requests: + pull_request5396
2017-07-22 08:04:22matheus.v.portelasetmessages: + msg298842
2017-07-22 08:03:50matheus.v.portelasetfiles: + issue1100942_20170722.patch
nosy: + matheus.v.portela
messages: + msg298841

2016-10-24 19:31:13belopolskysetmessages: + msg279334
2016-10-24 19:30:09belopolskysetmessages: + msg279333
2016-10-24 19:19:18matrixisesetmessages: + msg279331
2016-09-14 21:57:57belopolskysetpriority: high ->
assignee: belopolsky ->
versions: + Python 3.7, - Python 3.6
2016-08-25 14:01:43mark.dickinsonsetnosy: - mark.dickinson
2016-08-24 14:24:05belopolskysetmessages: + msg273568
2016-08-08 07:39:12BreamoreBoysetnosy: - BreamoreBoy
2016-08-08 07:11:59matrixisesetfiles: + issue1100942-3.6.patch
versions: + Python 3.6, - Python 3.5
nosy: + matrixise

messages: + msg272149
2015-05-11 21:23:04maciej.szuliksetfiles: + issue1100942.patch

messages: + msg242917
2015-05-09 12:33:44berker.peksagsetmessages: + msg242809
stage: needs patch -> patch review
2015-05-09 09:51:46maciej.szuliksetmessages: + msg242803
2015-05-04 18:56:47BreamoreBoysetnosy: + BreamoreBoy
messages: + msg242569
2014-04-10 07:39:55maciej.szuliksethgrepos: - hgrepo232
2014-04-09 20:05:37maciej.szuliksetfiles: + issue1100942_20140409.patch
hgrepos: + hgrepo232
messages: + msg215843
2014-04-04 19:40:09maciej.szuliksetmessages: + msg215559
2014-04-04 17:11:04belopolskysetmessages: + msg215537
2014-04-04 05:45:52maciej.szuliksetmessages: + msg215491
2014-04-03 21:53:41belopolskysetmessages: + msg215474
2014-04-03 21:39:50maciej.szuliksetmessages: + msg215472
2014-02-17 23:44:14westley.martinezsetnosy: + westley.martinez
2014-02-03 15:40:36BreamoreBoysetnosy: - BreamoreBoy
2013-12-20 23:28:19maciej.szuliksetfiles: + issue1100942_full.patch

messages: + msg206717
2013-12-18 14:33:11berker.peksagsetversions: + Python 3.5, - Python 3.4
2013-12-18 14:17:18Julian.Gindisetmessages: + msg206519
2013-12-18 07:54:51maciej.szuliksetmessages: + msg206500
2013-12-18 06:24:24vajraskysetnosy: + vajrasky
messages: + msg206498
2013-12-18 05:05:13Julian.Gindisetnosy: + Julian.Gindi
messages: + msg206495
2013-12-10 20:48:57maciej.szuliksetnosy: + maciej.szulik
2013-03-19 01:08:07jafosetnosy: + jafo
messages: + msg184577
2013-02-18 19:25:35berker.peksagsetfiles: + issue1100942_v4.diff
nosy: + berker.peksag
messages: + msg182336

2013-02-02 12:24:29petresetnosy: + petre
2013-01-22 21:39:42adam-collardsetnosy: + adam-collard
2012-11-04 04:18:15eric.araujosetversions: + Python 3.4, - Python 3.3
2012-11-04 03:01:22belopolskysetmessages: + msg174746
2012-11-04 02:46:45BreamoreBoysetnosy: + BreamoreBoy
messages: + msg174743
2012-07-20 17:32:56cvrebertsetnosy: + cvrebert
2012-07-20 14:18:49Juarez.Bochisetfiles: + issue1100942_pure2.diff

messages: + msg165929
2012-07-20 09:19:23Juarez.Bochisetfiles: - issue1100942_pure.diff
2012-07-20 09:19:09Juarez.Bochisetfiles: + issue1100942_pure.diff

messages: + msg165906
2012-07-20 09:09:48Juarez.Bochisetfiles: - issue1100942_pure.diff
2012-07-20 09:09:13Juarez.Bochisetfiles: + issue1100942_pure.diff

messages: + msg165905
2012-07-19 22:00:23Juarez.Bochisetfiles: + issue1100942_pure.diff
nosy: + Juarez.Bochi
messages: + msg165882

2012-06-13 21:44:06belopolskysetpriority: normal -> high

messages: + msg162732
2011-01-11 15:43:19belopolskysetnosy: guettli, amaury.forgeotdarc, mark.dickinson, belopolsky, sonderblade, alanvgreen, ajaksu2, josh-sf, tiktuk
versions: + Python 3.3, - Python 3.2
messages: + msg126013
stage: patch review -> needs patch
2010-08-18 16:39:56belopolskysetmessages: + msg114247
2010-06-09 15:17:23belopolskysetkeywords: + easy, patch
files: + issue1100942.diff
messages: + msg107402
2010-05-31 19:45:14mark.dickinsonsetmessages: + msg106807
2010-05-31 19:23:21belopolskysetversions: + Python 3.2, - Python 2.7
nosy: + mark.dickinson

messages: + msg106805

stage: test needed -> patch review
2010-05-25 23:55:45belopolskysetassignee: belopolsky
nosy: + belopolsky, - Alexander.Belopolsky
2010-04-20 16:12:34Alexander.Belopolskysetmessages: + msg103732
2010-04-20 16:02:17Alexander.Belopolskysetnosy: + Alexander.Belopolsky
messages: + msg103731
2009-12-02 13:21:19guettlisetnosy: + guettli
2009-06-23 23:18:59amaury.forgeotdarcsetfiles: + date-strptime.patch

nosy: + amaury.forgeotdarc
messages: + msg89650

keywords: + needs review, - patch
2009-06-22 15:17:34tiktuksetnosy: + tiktuk
2009-02-14 19:08:51ajaksu2setnosy: + ajaksu2
versions: + Python 2.7, - Python 2.6
stage: test needed
messages: + msg82109
title: datetime.strptime constructor added -> Add datetime.time.strptime and
2008-01-06 12:35:14christian.heimessettype: enhancement
versions: + Python 2.6
2005-01-12 14:53:01josh-sfcreate