classification
Title: strptime should implement %G, %V and %u directives
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.6
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: belopolsky Nosy List: AaronR, Alex.Willmer, BreamoreBoy, Erik Cederstrand, Erik.Cederstrand, aganders3, belopolsky, berker.peksag, python-dev, r.david.murray, serhiy.storchaka, tim.peters
Priority: normal Keywords: easy, patch

Created on 2011-05-05 10:03 by Erik.Cederstrand, last changed 2015-10-06 17:32 by belopolsky. This issue is now closed.

Files
File name Uploaded Description Edit
12006_2.patch aganders3, 2011-05-25 19:30 review
test_strptime.py.patch Erik.Cederstrand, 2011-05-26 12:46 Adds unit tests for %V and %u
_strptime.py.patch Erik.Cederstrand, 2011-05-26 12:52
12006_3.patch aganders3, 2011-05-26 22:38 Adds %G, %u, and %V to strptime(), tests are included review
12006_doc.patch aganders3, 2011-06-03 22:02 review
12006_3.5_complete.patch Alex.Willmer, 2014-08-19 22:59 Functionality, tests and docs combined for 3.5 tip review
issue12006_5.patch serhiy.storchaka, 2015-03-20 05:52 review
issue12006_6.patch serhiy.storchaka, 2015-03-20 07:48 review
issue12006_7_complete.patch aganders3, 2015-07-31 16:57 Add ISO 8601 directives for strptime, tests, and docs. All against 3.6 tip. review
issue12006_8_complete.patch aganders3, 2015-08-03 03:28 review
issue12006_10_complete.patch aganders3, 2015-10-02 17:30 Fixed error in docs from code review, updated against tip review
Messages (56)
msg135177 - (view) Author: Erik Cederstrand (Erik.Cederstrand) Date: 2011-05-05 10:03
Python is via datetime.isocalendar() able to produce the ISO week number and ISO weekday from a given date. But it is not possible to do the reverse; calculate the date from a year, ISO week number and weekday.

libc strptime()/strftime() mentions a %V and %u directive which does this, i.e. Monday in ISO week 22 of the year 2011:

   datetime.strptime('2011221', '%Y%V%u')

returning 2011-05-30 and

   datetime.strptime('2011227', '%Y%V%u')

returning 2011-06-05


libc (on FreeBSD) has this to say:

%V is replaced by the week number of the year (Monday as the first day
   of the week) as a decimal number (01-53).  If the week containing
   January 1 has four or more days in the new year, then it is week 1;
   otherwise it is the last week of the previous year, and the next
   week is week 1.

%u is replaced by the weekday (Monday as the first day of the week) as
   a decimal number (1-7).
msg135208 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2011-05-05 14:34
This is a reasonable request and easy to implement.  I am not sure how often this functionality is needed, so I am only +0 on this feature.
msg135237 - (view) Author: Erik Cederstrand (Erik.Cederstrand) Date: 2011-05-05 19:24
At least in Denmark, week numbers are used regularly in everyday communication and planning, and the numbering follows the ISO rules. Also, the week starts on Monday.
msg136821 - (view) Author: Ashley Anderson (aganders3) * Date: 2011-05-25 01:49
I've recently joined the python-mentors mailing list because I love Python and want to get involved. I found this bug in the list of "Easy issues" and thought I'd try my hand. Anyway, this is my first patch, so please forgive me if I am breaking protocol or stepping on anyone's toes here. I also hope my code isn't embarrassing.

This adds a constructor to the date class that allows construction based on an ISO-8601 YYYYWWD string. Does this address the issue in a logical way?
msg136822 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2011-05-25 02:26
Thanks for wanting to work on this.

It is a little hard to parse from the OP's initial post, but he is asking that %V and %u be supported by datetime.strptime, which they currently are not.  strptime is the generalized constructor for turning a string into a datetime, so no, a new constructor is not the right approach.

The code that implements the strptime method of datetime is in the file _strptime.py in Lib.  Your patch should be against that code.  (Note that this is pretty un-obvious, I had to dig a bit to figure it out!)
msg136825 - (view) Author: Ashley Anderson (aganders3) * Date: 2011-05-25 03:56
Thanks, I think I understand the original post now. Upon reading the docs and code, however, it seems this is possible using the %W and %w directives. Is the issue just to support the different letters (%V and %u) specifically, or that they are not quite the same format as the corresponding ISO numbers?
msg136828 - (view) Author: Erik Cederstrand (Erik.Cederstrand) Date: 2011-05-25 06:25
Getting a date from ISO week /weekday is not possible with the %W and %w directives. ISO week numbers and normal week numbers are calculated differently (see my libc qoute in the original post). Also, using %w instead of %u would be ambiguous, since %w weeks start on Sunday, while %u start with Monday.

I agree that this should be implemented in strptime(), to follow libc strptime(). datetime() has a clear constructor while strptime() has all the whacky cases.
msg136886 - (view) Author: Ashley Anderson (aganders3) * Date: 2011-05-25 19:30
OK, here is my second attempt. I think it functions as desired, but a code review may reveal flaws in my implementation. I'm sure there are associated tests and documentation to write, but I have basically no experience with that yet. If this looks like the right direction, I can take it to the python-mentors list for help with the test/docs.
msg136896 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2011-05-25 20:43
I'm not familiar with this module, so at the moment I just gave the patch a quick scan.  The approach looks OK to me.  Hopefully Alexander can review it.  In the meantime I think you should go ahead and work on tests and doc.  It is easier to do a detailed review when tests are included.
msg136899 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2011-05-25 20:56
I'll try to give this a more  thorough review by the end of the week.  For now, just a nit-pick, but _calc_julian_from_V jumped at me as a really odd name.  Either "iso_to_julian" or "julian_from_iso" would be much clearer.  The patch also needs tests and documentation.
msg136914 - (view) Author: Ashley Anderson (aganders3) * Date: 2011-05-25 22:28
Thanks everyone, please take your time if there are more pressing issues; I'll get to work on tests and documentation in the mean time. I agree that '_calc_julian_from_V' is a bit strange. I was mimicking a similar helper function's name ('_calc_julian_from_U_or_W'), but perhaps that is no defense.

Also, I know the functionality is there with 'toisocalendar' and 'toisoweekday', but maybe %V and %u should be implemented for 'strftime' for completeness. Any thoughts?
msg136923 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2011-05-26 00:16
On Wed, May 25, 2011 at 6:28 PM, Ashley Anderson <report@bugs.python.org> wrote:
>
> .. I agree that '_calc_julian_from_V' is a bit strange. I was mimicking a similar helper function's
> name ('_calc_julian_from_U_or_W'), but perhaps that is no defense.

This is a perfect defense.  Local consistency usually trumps global
conventions.  I only looked at the patch and did not see that other
function.  Please don't change the name.
msg136924 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2011-05-26 01:24
It looks like strftime already support %V and %u (presumably if and only if the platform strftime does).
msg136954 - (view) Author: Erik Cederstrand (Erik.Cederstrand) Date: 2011-05-26 12:46
Uploaded patch adding unit tests for %V and %u. Patch is against python2.7
msg136955 - (view) Author: Erik Cederstrand (Erik.Cederstrand) Date: 2011-05-26 12:52
Patch by aganders3 doesn't compile. Added comments in review of his patch. Adding a patch against python2.7 with my changes, which pass all unit tests posted previously.
msg136956 - (view) Author: Erik Cederstrand (Erik.Cederstrand) Date: 2011-05-26 13:04
Documentation (I have no idea how to create a patch for this):

%V ISO week number of the year (Monday as the first day of the week) as a decimal number (01-53). The week containing January 4 is week 1;
the previous week is the last week of the previous year.

%u ISO weekday (Monday as the first day of the week) as a decimal number (1-7).
msg136960 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2011-05-26 13:44
Since this is a new feature it can only go into 3.3.

Documentation is in the Doc subdirectory of a checkout, and is in the form of *.rst files.  Modify the appropriate .rst file, and the doc update will be included in the patch you generate.  If you wish to test your doc patch, execute 'make html' in the Doc subdirectory, which will pull in the appropriate software and build the docs in a Doc/build/html subdirectory.

Ashely's patch worked for me on 3.3 in a minimal test; I haven't looked it it further at this point.

Thanks for reviewing and for working on the unit tests and docs.
msg136965 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2011-05-26 14:21
On Thu, May 26, 2011 at 9:44 AM, R. David Murray <report@bugs.python.org> wrote:
..
> Documentation is in the Doc subdirectory of a checkout, and is in the form of *.rst files.  Modify the appropriate .rst file,

More specifically, strftime/strptime directives are listed in a table
inside the the Doc/library/datetime.rst file.  Note that the narrative
before the table says that only C89 standard codes are listed and I
don't think %V and %u are standard.  Check if there is an applicable
standard for them - C99 and POSIX define more codes that C89.
msg136976 - (view) Author: Ashley Anderson (aganders3) * Date: 2011-05-26 16:07
When trying to add cases for %V and %u in the tests, I ran into an issue of year ambiguity. The problem comes when the ISO year does not match the Gregorian year for a given date. I think this should be fixed by implementing the %G directive (ISO year, which is present in strftime) as well.
msg136977 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2011-05-26 16:15
On Thu, May 26, 2011 at 12:07 PM, Ashley Anderson
<report@bugs.python.org> wrote:
> I think this should be fixed by implementing the %G directive (ISO year, which is present in strftime) as well.

Correct.
msg136990 - (view) Author: Erik Cederstrand (Erik.Cederstrand) Date: 2011-05-26 18:18
Ashley, can you elaborate on wherein the ambiguity lies? Which combination of year, ISO week number and ISO weekday would lead to ambiguity?

Regarding documentation, the %G, %V and %u directives are listed in IEEE Std 1003.1, 2004 Edition for strftime(): http://pubs.opengroup.org/onlinepubs/009695399/functions/strftime.html

For some reason, these directives are not mentioned in the related strptime(): http://pubs.opengroup.org/onlinepubs/009695399/functions/strptime.html
msg136995 - (view) Author: Ashley Anderson (aganders3) * Date: 2011-05-26 19:16
The example that triggered the issue in testing was January 1, 1905. The ISO date for this day is 1904 52 7. This is reported correctly if you use datetime.isocalendar() or datetime.strftime('%G'), but you get 1905 if you use datetime.strftime('%Y'). When it's read back in it causes the test to fail because ISO '1904 52 7' is different from ISO '1905 52 7'.

Likewise if you consider a year starting on a Tuesday, Wednesday, or Thursday, there will be several days at the end of the previous year that will have an ISO year ahead of their Gregorian representation.
msg137002 - (view) Author: Erik Cederstrand (Erik.Cederstrand) Date: 2011-05-26 20:00
Oh, I see, you're talking about strftime(). You're correct that you would need %G to print the year to which the ISO week containing the specific date belongs. I see no ambiguity or need for %G in strptime().
msg137012 - (view) Author: Ashley Anderson (aganders3) * Date: 2011-05-26 22:38
I disagree, I think %G is necessary in strptime(). Take Monday, December 31, 2001 as an example. The ISO date is 2002 01 1.

Now, given only the Gregorian year (2001) for this date, and the ISO week and weekday (01 1), there is an ambiguity with Monday, January 1, 2001, which has an ISO date of 2001 01 1. The ISO week/weekday combination of (01 1) occurs twice in the year 2001, and can only be differentiated by the corresponding ISO year.

We can, of course, debate on what the behavior in this case should be. The way I see it, we can:
1) Assume the year taken in by %Y is equivalent to the ISO year, which it often is. Assuming %Y is the ISO year IFF %V is used accomplishes the same result.
2) Default the year to some value, currently 1900 is used when %Y is absent. This is how it is handled now.
3) Report an error/exception that insufficient data was provided, and maybe mention %G should be used instead of %Y for this case.

I'm attaching a patch now that includes some minor changes, includes %G and adds some tests. I am also working on the documentation but it's not quite ready.
msg137030 - (view) Author: Erik Cederstrand (Erik.Cederstrand) Date: 2011-05-27 07:28
I respectfully disagree. I take strptime('2002 01 1', '%Y %V %u') as mening "first day of first week in the year 2002"

There is only one date that corresponds to the first day of the first week of 2002, i.e. Dec. 31, 2001. If you specify the first day of the first week of 2001 instead, then that's another date (Jan. 1, 2001). The last and the first week in a year may span dates belonging to two years.  That's just the way it is.

Are you suggesting strptime('2002 01 1', '%Y %V %u') to mean "first day of first week of 2002, except if that would change the year, in which case it means ???"

If you want to strftime(strptime(date, fmt), fmt) and arrive at the original date then yes, you need %G (but only in strftime).
msg137038 - (view) Author: Erik Cederstrand (Erik.Cederstrand) Date: 2011-05-27 08:43
Reading you comment again, I see the ambiguity now, if %Y is interpreted as "The resulting date MUST be in 2001".

I think the safest way would be to implement %G and fail if %Y is used in combination with %V. Maybe even fail if %V and %u aren't used in combination (since using %w could mean either the Sunday in the end of ISO week X or the Sunday preceeding ISO week X).
msg137597 - (view) Author: Ashley Anderson (aganders3) * Date: 2011-06-03 22:02
Attaching a patch for the documentation just in time for the weekend!
msg179529 - (view) Author: Erik Cederstrand (Erik Cederstrand) Date: 2013-01-10 07:25
Ping. Is anyone willing to take this? I'm not a committer nor know anyone with commit access.
msg221927 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2014-06-30 00:19
Ashley,

I would like to include your patch in 3.5.  Can you combine your doc and code changes in one diff and make sure it is up to date with the tip.

Thanks.
msg227259 - (view) Author: Alex Willmer (Alex.Willmer) * Date: 2014-09-22 10:03
Alexander, 

http://bugs.python.org/file36417/12006_3.5_complete.patch updates the previous patches and is ready for review. Unit tests pass as of today. 

Regards, Alex W.
msg227274 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2014-09-22 14:52
I find this footnote somewhat confusing:

"""
(8) Similar to %U and %W, %V is only used in calculations when the day of the week and the ISO year (%G) are specified when used with the strptime method.
"""

The existing footnote (7) is much clearer:

"""
(7) When used with the strptime() method, %U and %W are only used in calculations when the day of the week and the year are specified.
"""

Why not use the same language in (8)?

"""
(7) When used with the strptime() method, %V is only used in calculations when the day of the week and the ISO year (%G) are specified.

"""
msg227275 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2014-09-22 15:02
How was "%Y %V" issue resolved?  I don't see any tests for this case.
msg227350 - (view) Author: Erik Cederstrand (Erik Cederstrand) Date: 2014-09-23 12:26
Well, it's an ambiguous situation, as established earlier. I'm not sure what the policy is wrt. foot-shooting, but I'd opt to fail if %G, %V and %u are not used together.
msg227409 - (view) Author: Erik Cederstrand (Erik Cederstrand) Date: 2014-09-24 07:17
I don't have the repo handy to make a patch against 3.5, but would an addition like this do?


in Lib/_strptime.py:

+    elif iso_week != -1 and iso_year == -1:
+        raise ValueError("'%Y' directive is ambiguous in combination with '%V'. Use '%G' instead.")
+    elif julian == -1 and iso_week != -1 and iso_weekday != -1:
+        year, julian = _calc_julian_from_V(iso_year, iso_week, iso_weekday)



In Lib/test/test_strptime.py:

    def test_ValueError(self):
+        # Make sure ValueError is raised when match fails or format is bad
+        self.assertRaises(ValueError, _strptime._strptime, data_string="1905 52",
+                          format="%Y %V")
msg227804 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2014-09-29 15:35
For future reference, here is the example showing %Y %V ambiguity:

>>> date(2013,12,31).strftime('%Y %V %u')
'2013 01 2'
>>> date(2013,1,1).strftime('%Y %V %u')
'2013 01 2'

which is resolved by using %G

>>> date(2013,12,31).strftime('%G %V %u')
'2014 01 2'
>>> date(2013,1,1).strftime('%G %V %u')
'2013 01 2'

In other words, '2013 01 2' cannot be unambiguously parsed using '%Y %V %u' format.
msg227805 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2014-09-29 15:44
I think we need more tests showing that new directives don't violate strftime - strptime round-trip invariants.
msg227806 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2014-09-29 15:47
Documentation should say "new in 3.5".
msg238549 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2015-03-19 18:01
It would be nice to get this in for 3.5.  Does anyone have time/interest to address the last two comments?
msg238605 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-03-20 05:52
The patch is synchronized with the tip, added the versionadded directives and whatsnews entry, addressed sasha's comment on Rietveld. Fixed a bug: %a and %A now are interchangeable with %u as well as with %w.

I don't understand what more test are needed. Existing tests cover %Y %V ambiguity:

>>> date(1906, 12, 31).strftime('%G %V %u')
'1907 01 1'
>>> date(1917, 12, 31).strftime('%G %V %u')
'1918 01 1'
msg238612 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-03-20 07:48
Addressed Berker's comments.
msg238649 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-03-20 11:32
There are other issues.

strptime with single %Y returns a date of the first day of the year. What should return single %G?

>>> time.strptime('2015', '%Y')
time.struct_time(tm_year=2015, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=3, tm_yday=1, tm_isdst=-1)
>>> time.strptime('2015', '%G')
time.struct_time(tm_year=1900, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=0, tm_yday=1, tm_isdst=-1)

See also issue23717 and issue23718.
msg241709 - (view) Author: Erik Cederstrand (Erik Cederstrand) Date: 2015-04-21 09:11
I think POLA would be to raise ValueError on time.strptime('2015', '%G') and other situations that don't make sense or are ambiguous.

That, or reproduce the bugs that the native OS strptime() implementation has. I got the %G, %V, and %u directives accepted for the next POSIX spec (http://austingroupbugs.net/view.php?id=879). But it will be years before operating systems catch up, so I would opt for the ValueError approach instead.
msg247384 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2015-07-25 19:47
Reverting to "needs patch" stage because there are still issues to be ironed out.
msg247525 - (view) Author: Ashley Anderson (aganders3) * Date: 2015-07-28 15:26
Wow, I can't believe this issue is so old now! I'm motivated to finally come
back and address the remaining issues to get this merged. Sorry for seemingly
abandoning this; I'm embarrassed I didn't push to finish it earlier.

It sounds like the consensus is to raise a ValueError in cases where ambiguity
may arise, with specific suggestions for resolving the ambiguity in each case.
This is in contrast to certain other cases where strptime uses some default
value for missing data (e.g. month/day = 1, year = 1900).

Ambiguous or incomplete cases I have identified are:
1. ISO week (%V) is specified, but the year is specified with %Y instead of %G
2. ISO year (%G) and ISO week (%V) are specified, but a weekday is not
3. ISO year (%G) and weekday are specified, but ISO week (%V) is not
4. ISO year is specified alone (e.g. time.strptime('2015', '%G'))
5. Julian/ordinal day (%j) is specified with %G, but not %Y

Hopefully that covers it...let me know if I need to add any cases or change
behavior in any cases. I can have a patch (at least an initial attempt) ready
for this in the next few days.
msg247755 - (view) Author: Ashley Anderson (aganders3) * Date: 2015-07-31 16:57
Here is an updated patch with implementation as outlined in msg247525.
msg247917 - (view) Author: Ashley Anderson (aganders3) * Date: 2015-08-03 03:28
Thanks for the review and the good suggestions. Hopefully this new patch is an improvement.

I didn't know about the context manager for assertRaises - I was just following the format for another ValueError test a few lines above.

The frozenset and re-wrapped comment were left from playing around with another way to do the checks, and I've corrected them.

I think the conditionals around calculating the julian and year are clearer now as well.

Please (obviously) let me know if there are further changes. Also please let me know if this is not the proper way to respond to the code review!
msg249529 - (view) Author: Erik Cederstrand (Erik Cederstrand) Date: 2015-09-02 08:47
The going's a bit tough here. I've spent at least 10 times as long on this bug than it took me to work around the fact that Python doesn't support ISO week number round-trip. Python puts a smile on my face every day and I enjoy giving back where I can. But after four years, the smile is getting a bit stiff when I look at this enhancement request. 

I'm hereby offering a scrumptious, mouth-watering, virtual, blackberry mousse gateau with a honey-roasted almond meringue cake bottom to the person who gets this enhancement committed. In good open-source spirit, everyone who contributed along the way is entitled to a healthy serving and eternal gratitude from me.

Bon appetit!
msg249543 - (view) Author: Ashley Anderson (aganders3) * Date: 2015-09-02 13:55
Haha, thanks Erik. It seems you know my tastes enough to not offer a chocolate-based reward. =)

I was actually set to "ping" to request a patch review today, as it's been one month since my last submission. Please let me know if I need to update the patch against the current `tip`.
msg251983 - (view) Author: Ashley Anderson (aganders3) * Date: 2015-10-01 00:34
Another *ping* for a patch review since it's been almost a month since the last one.
msg251986 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2015-10-01 01:24
Ashley,

You don't have to be a committer to review a patch.  Given that it is unlikely that any of the committers is an expert on ISO calendar, an external review will be most welcome.  Would you complete one?
msg251988 - (view) Author: Ashley Anderson (aganders3) * Date: 2015-10-01 02:18
Thanks Alexander, but I think the latest patch is still mine. It seems strange to review my own patch. I'll do it if that's common, but since this will (hopefully, eventually) be my first accepted patch I would appreciate the feedback from another reviewer.
msg252139 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2015-10-02 16:22
My bad.  In this case, maybe Erik can review your latest patch?
msg252146 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2015-10-02 17:15
> Also please let me know if this is not the proper way to respond to the code review!

I believe Rietveld gives you a "done" button on each reviewer comment.  If all you do is to take the reviewer suggestion, you can just press it.

Responding with an issue note as you did is perfectly fine as well.
msg252383 - (view) Author: Erik Cederstrand (Erik Cederstrand) Date: 2015-10-06 10:26
I have reviewed the latest patch, and it looks good to me. There are tests for the tricky conversions around Jan 1, and the docs are brief and succinct. Until the full set of new c99 strftime directives are supported, I think it's overkill to include a lecture about the origin of these new directives and their support in the underlying OS.

There are a number of foot-shooting possibilities when parsing date strings with the directives supported by strptime(), but at least this patch does not make it worse. It validates the input nicely when using the new directives and prints useful error messages it input is ambiguous.

I'm not a committer, but I approve of the patch as-is.
msg252413 - (view) Author: Roundup Robot (python-dev) Date: 2015-10-06 17:30
New changeset acdebfbfbdcf by Alexander Belopolsky in branch 'default':
Closes issue #12006: Add ISO 8601 year, week, and day directives to strptime.
https://hg.python.org/cpython/rev/acdebfbfbdcf
msg252414 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2015-10-06 17:32
I've committed the latest patch.  Thank you Ashley and Erik for your work and perseverance.
History
Date User Action Args
2015-10-06 17:32:47belopolskysetstatus: open -> closed
resolution: fixed
messages: + msg252414

stage: patch review -> resolved
2015-10-06 17:30:06python-devsetnosy: + python-dev
messages: + msg252413
2015-10-06 10:26:27Erik Cederstrandsetmessages: + msg252383
2015-10-02 22:00:19belopolskylinkissue14423 superseder
2015-10-02 17:31:02aganders3setfiles: + issue12006_10_complete.patch
2015-10-02 17:15:16belopolskysetmessages: + msg252146
2015-10-02 16:22:40belopolskysetmessages: + msg252139
2015-10-01 02:18:09aganders3setmessages: + msg251988
2015-10-01 01:24:03belopolskysetmessages: + msg251986
2015-10-01 00:34:29aganders3setmessages: + msg251983
2015-09-02 14:45:39berker.peksagsetstage: needs patch -> patch review
2015-09-02 13:55:49aganders3setmessages: + msg249543
2015-09-02 08:47:23Erik Cederstrandsetmessages: + msg249529
2015-08-03 03:28:19aganders3setfiles: + issue12006_8_complete.patch

messages: + msg247917
2015-07-31 16:57:23aganders3setfiles: + issue12006_7_complete.patch

messages: + msg247755
2015-07-28 15:26:24aganders3setmessages: + msg247525
2015-07-25 19:47:24belopolskysetstage: commit review -> needs patch
messages: + msg247384
versions: + Python 3.6, - Python 3.5
2015-04-21 09:11:58Erik Cederstrandsetmessages: + msg241709
2015-03-20 11:32:00serhiy.storchakasetmessages: + msg238649
2015-03-20 07:48:12serhiy.storchakasetfiles: + issue12006_6.patch

messages: + msg238612
2015-03-20 05:52:23serhiy.storchakasetfiles: + issue12006_5.patch

messages: + msg238605
2015-03-19 22:33:27berker.peksagsetnosy: + berker.peksag
2015-03-19 18:01:45belopolskysetnosy: + serhiy.storchaka
messages: + msg238549
2014-09-29 15:47:42belopolskysetmessages: + msg227806
2014-09-29 15:44:28belopolskysetmessages: + msg227805
title: strptime should implement %V or %u directive from libc -> strptime should implement %G, %V and %u directives
2014-09-29 15:35:36belopolskysetmessages: + msg227804
2014-09-24 07:17:46Erik Cederstrandsetmessages: + msg227409
2014-09-23 12:26:23Erik Cederstrandsetmessages: + msg227350
2014-09-22 15:02:07belopolskysetmessages: + msg227275
2014-09-22 14:52:34belopolskysetnosy: + tim.peters
messages: + msg227274
2014-09-22 10:03:02Alex.Willmersetnosy: + Alex.Willmer
messages: + msg227259
2014-08-19 23:05:23BreamoreBoysetnosy: + BreamoreBoy
2014-08-19 22:59:42Alex.Willmersetfiles: + 12006_3.5_complete.patch
2014-06-30 00:19:03belopolskysetstage: patch review -> commit review
messages: + msg221927
versions: + Python 3.5, - Python 3.3
2013-01-10 07:25:33Erik Cederstrandsetnosy: + Erik Cederstrand
messages: + msg179529
2011-08-11 22:17:17AaronRsetnosy: + AaronR
2011-06-03 22:02:34aganders3setfiles: + 12006_doc.patch

messages: + msg137597
2011-05-27 08:43:42Erik.Cederstrandsetmessages: + msg137038
2011-05-27 07:28:25Erik.Cederstrandsetmessages: + msg137030
2011-05-26 22:38:04aganders3setfiles: + 12006_3.patch

messages: + msg137012
2011-05-26 20:00:09Erik.Cederstrandsetmessages: + msg137002
2011-05-26 19:16:42aganders3setmessages: + msg136995
2011-05-26 18:18:33Erik.Cederstrandsetmessages: + msg136990
2011-05-26 16:15:13belopolskysetmessages: + msg136977
2011-05-26 16:07:47aganders3setmessages: + msg136976
2011-05-26 14:21:58belopolskysetmessages: + msg136965
2011-05-26 13:44:34r.david.murraysetmessages: + msg136960
2011-05-26 13:04:36Erik.Cederstrandsetmessages: + msg136956
2011-05-26 12:52:12Erik.Cederstrandsetfiles: + _strptime.py.patch

messages: + msg136955
2011-05-26 12:46:51Erik.Cederstrandsetfiles: + test_strptime.py.patch

messages: + msg136954
2011-05-26 01:24:42r.david.murraysetmessages: + msg136924
2011-05-26 00:16:42belopolskysetmessages: + msg136923
2011-05-25 22:28:42aganders3setmessages: + msg136914
2011-05-25 20:56:44belopolskysetassignee: belopolsky
messages: + msg136899
stage: needs patch -> patch review
2011-05-25 20:43:05r.david.murraysetmessages: + msg136896
2011-05-25 19:30:25aganders3setfiles: - 12006.patch
2011-05-25 19:30:16aganders3setfiles: + 12006_2.patch

messages: + msg136886
2011-05-25 06:25:30Erik.Cederstrandsetmessages: + msg136828
2011-05-25 03:56:24aganders3setmessages: + msg136825
2011-05-25 02:26:55r.david.murraysetnosy: + r.david.murray
messages: + msg136822
2011-05-25 01:49:30aganders3setfiles: + 12006.patch
keywords: + patch
messages: + msg136821
2011-05-24 23:16:11aganders3setnosy: + aganders3
2011-05-05 19:24:46Erik.Cederstrandsetmessages: + msg135237
2011-05-05 14:34:44belopolskysetkeywords: + easy

stage: needs patch
messages: + msg135208
versions: + Python 3.3
2011-05-05 10:20:07ezio.melottisetnosy: + belopolsky
2011-05-05 10:03:42Erik.Cederstrandcreate