Issue1045381
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.
Created on 2004-10-12 14:04 by sebastienjust, last changed 2022-04-11 14:56 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
fix_year_start_end_Monday.diff | brett.cannon, 2004-10-19 20:10 | handle when day of week and Jan 1 is a Monday and %U (diff'ed against CVS) |
Messages (19) | |||
---|---|---|---|
msg22635 - (view) | Author: Sebastien JUST (sebastienjust) | Date: 2004-10-12 14:04 | |
It seems that strptime() ignores %U. For example when trying to get the first day of the 42th week of year 2004. Please test on the command line : import time time.strftime("%Y-%m-%d",time.strptime("2004 42 1","%Y %U %w")) the result is 2004-01-01 and not 2004-10-11 seems that strptime() is ignoring %U indications. Works fine on Python 2.2, bad on Python 2.3.3 , 2.3.4 and 2.4a1. Tested on Fedora Core 2. Thanks |
|||
msg22636 - (view) | Author: Brett Cannon (brett.cannon) * | Date: 2004-10-13 01:42 | |
Logged In: YES user_id=357491 Yeah, right now it isn't supported since the calculation, at least when I first implemented strptime() seemed useless in terms of reversing back into a time tuple. Guess there at least one way there is enough info to make it useful. Now I just need to figure out how to make the calculation work. |
|||
msg22637 - (view) | Author: Brett Cannon (brett.cannon) * | Date: 2004-10-13 01:57 | |
Logged In: YES user_id=357491 Well, it looks like glibc 2.3.x doesn't even support %U or %W for strptime(); this might take a while to implement... |
|||
msg22638 - (view) | Author: Brett Cannon (brett.cannon) * | Date: 2004-10-13 01:57 | |
Logged In: YES user_id=357491 Forgot the link to the glibc page: http://www.gnu.org/software/libc/ manual/html_node/Low-Level-Time-String-Parsing.html#Low- Level%20Time%20String%20Parsing |
|||
msg22639 - (view) | Author: Brett Cannon (brett.cannon) * | Date: 2004-10-17 23:10 | |
Logged In: YES user_id=357491 OK, I have the algorithm written. Now I am waiting for python-dev to make a decision on whether this should go into 2.4b2 or wait until 2.5 . |
|||
msg22640 - (view) | Author: Brett Cannon (brett.cannon) * | Date: 2004-10-18 01:56 | |
Logged In: YES user_id=357491 In rev. 1.36 in HEAD has the fix as well as rev. 1.23.4.6 for 2.3 . |
|||
msg22641 - (view) | Author: Tony Meyer (anadelonbrin) | Date: 2004-10-18 03:50 | |
Logged In: YES user_id=552329 FWIW, with the example given the correct answer is 2004-10-18, which CVS now gives, not 2004-10-11. However, this doesn't look right: >>> time.strptime("2008 52 1", "%Y %U %w") (2009, 1, 5, 0, 0, 0, 0, 371, -1) It ought to be >>> time.strptime("2008 52 1", "%Y %U %w") (2008, 12, 29, 0, 0, 0, 0, 364, -1) By my figuring. |
|||
msg22642 - (view) | Author: Brett Cannon (brett.cannon) * | Date: 2004-10-18 18:45 | |
Logged In: YES user_id=357491 Reopening to deal with the error Tony caught. Tony, can you apply the included patch and verify it works for you okay? I added another if to track back a week if the calculation gets pushed past 366 days. That does fix your error. And if you can think of any other edge cases let me know. I think that should cover everything. And yes, the example for the OP is wrong:: >>> datetime.date(2004, 10, 11).strftime("%Y %U %w") '2004 41 1' |
|||
msg22643 - (view) | Author: Tony Meyer (anadelonbrin) | Date: 2004-10-19 07:31 | |
Logged In: YES user_id=552329 Patch works for that case, yes. However... [from python-dev] > the test case I was using that triggered > the need for that is 1906-12-31 > which is a Monday but changes what week > it is based on whether you use U or W. > which makes no sense since both U and W > should consider it the same week. > Had the same result for 1917-12-31. Something's still not right here (this is with the patch): >>> time.strptime("1917 51 1", "%Y %U %w") (1917, 12, 17, 0, 0, 0, 0, 351, -1) >>> time.strptime("1917 52 1", "%Y %U %w") (1917, 12, 31, 0, 0, 0, 0, 365, -1) 1917 both started and ended on a Monday, so there are 53 U weeks, right? (where the last 'week' is only one day). So 31/12/1917 should be U=53, W=52 |
|||
msg22644 - (view) | Author: Nick Coghlan (ncoghlan) * | Date: 2004-10-19 09:57 | |
Logged In: YES user_id=1038590 The calculation of 'preceeding_days' looks incorrect. It assumes that the week starts on day 0 - it needs to adjust for when "week_of year_start" is 6. |
|||
msg22645 - (view) | Author: Nick Coghlan (ncoghlan) * | Date: 2004-10-19 10:03 | |
Logged In: YES user_id=1038590 Scratch the last comment - I missed the wee_of_year adjustment at the top of the function. |
|||
msg22646 - (view) | Author: Nick Coghlan (ncoghlan) * | Date: 2004-10-19 10:39 | |
Logged In: YES user_id=1038590 Taking out the "add one to the week" condition, I get the following for 1906 and 1917: ./python -c "import time; print time.strptime('1906 53 1', '%Y %W %w')" (1906, 12, 31, 0, 0, 0, 0, 365, -1) ./python -c "import time; print time.strptime('1906 53 1', '%Y %U %w')" (1906, 12, 31, 0, 0, 0, 0, 365, -1) ./python -c "import time; print time.strptime('1917 53 1', '%Y %W %w')" (1917, 12, 31, 0, 0, 0, 0, 365, -1) ./python -c "import time; print time.strptime('1917 53 1', '%Y %U %w')" (1917, 12, 31, 0, 0, 0, 0, 365, -1) So, I'm more than a little curious about the details of the "bug" that was being fixed. |
|||
msg22647 - (view) | Author: Nick Coghlan (ncoghlan) * | Date: 2004-10-19 10:42 | |
Logged In: YES user_id=1038590 I forgot to add that I'm on Linux (Fedora Core 3 Test 1 + misc updates) |
|||
msg22648 - (view) | Author: Nick Coghlan (ncoghlan) * | Date: 2004-10-19 10:50 | |
Logged In: YES user_id=1038590 Any bug is in datetime.date, not strptime. I tried datetime.date(1917, 12, 31).strftime("%Y %U %w") and saw Brett's incorrect calculation of the week. ./python -c "import datetime; print datetime.date(1917, 12, 31).strftime('%Y %W %w')" 1917 53 1 ./python -c "import datetime; print datetime.date(1917, 12, 31).strftime('%Y %U %w')" 1917 52 1 December 31 should be week 53 under %U as well. |
|||
msg22649 - (view) | Author: George Yoshida (quiver) | Date: 2004-10-19 12:18 | |
Logged In: YES user_id=671362 > December 31 should be week 53 under %U as well. I doubt it. Year 1917 begins on Monday and ends on Monday. So "%U"(Sunday as the first day of the week) should return 52 and "W"(Monday as the first day of the week) should return 53. $ cal 1 1917 January 1917 Su Mo Tu We Th Fr Sa 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 $ cal 12 1917 December 1917 Su Mo Tu We Th Fr Sa 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
|||
msg22650 - (view) | Author: Nick Coghlan (ncoghlan) * | Date: 2004-10-19 13:18 | |
Logged In: YES user_id=1038590 Under %W, the first week contains a full 7 days, but it only contains 6 days under %U. Either way, we end up with a week 53 - it contains 1 day for %W, but 2 days for %U. In both cases, December 31st is the Monday of week 53. Unless I'm misunderstanding how this is meant to work, and Week 1 is always the first full week of the year, with an optional Week 0 before it (which would always have fewer than 7 days, and doesn't exist at all if the year and the week start on the same day). If I *am* misunderstanding, then that's the bug in strptime - it currently works in accordance with my understanding. |
|||
msg22651 - (view) | Author: Brett Cannon (brett.cannon) * | Date: 2004-10-19 20:10 | |
Logged In: YES user_id=357491 Nick is seeing things the way I thought they are supposed to be; how can ending on a Monday make any difference for %U or %W? Both start at after the beginning of the week, right? Well, as George was pointing out, it shifts everything by a full week depending on the directive when the year starts on a Monday. So under %U week 1 doesn't start until the first Sunday, while under %W week 1 starts on Jan 1. So the issue is when a year starts and end on a Monday, we are looking at Monday, but %U is used. So the new patch attempts to handle this case. I am now testing against the following dates: test_helper((1901, 1, 3), "week 0") test_helper((1901, 1, 8), "common case") test_helper((1901, 1, 13), "day on Sunday") test_helper((1901, 1, 14), "day on Monday") test_helper((1905, 1, 1), "Jan 1 on Sunday") test_helper((1906, 1, 1), "Jan 1 on Monday") test_helper((1906, 1, 7), "first Sunday in a year starting on Monday") test_helper((1905, 12, 31), "Dec 31 on Sunday") test_helper((1906, 12, 31), "Dec 31 on Monday") test_helper((2008, 12, 29), "Monday in the last week of the year") test_helper((2008, 12, 22), "Monday in the second-to-last week of the " "year") test_helper((1978, 10, 23), "randomly chosen date") test_helper((2004, 12, 18), "randomly chosen date") test_helper((1978, 10, 23), "year starting and ending on Monday while " "date not on Sunday or Monday") test_helper((1917, 12, 17), "year starting and ending on Monday with " "a Monday not at the beginning or end " "of the year") test_helper((1917, 12, 31), "Dec 31 on Monday with year starting and " "ending on Monday") |
|||
msg22652 - (view) | Author: Brett Cannon (brett.cannon) * | Date: 2004-10-26 03:01 | |
Logged In: YES user_id=357491 OK, unless someone speaks up about this patch I will apply it sometime this week (soonest being 2004-10-26 in the evening PDT). |
|||
msg22653 - (view) | Author: Brett Cannon (brett.cannon) * | Date: 2004-10-28 04:51 | |
Logged In: YES user_id=357491 For Lib/_strptime.py, rev. 1.38 on HEAD and 1.23.4.7 on 2.3 and Lib/test/ test_strptime.py, rev. 1.29 on HEAD and 1.23.4.6 on 2.3 have the fix and extra test cases. Bug fixed and closed... again. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:56:07 | admin | set | github: 41006 |
2004-10-12 14:04:17 | sebastienjust | create |