[ python-Bugs-1045381 ] strptime doesn't work with %U

SourceForge.net noreply at sourceforge.net
Tue Oct 19 15:18:29 CEST 2004


Bugs item #1045381, was opened at 2004-10-13 00:04
Message generated for change (Comment added) made by ncoghlan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1045381&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 4
Submitted By: Sebastien JUST (sebastienjust)
Assigned to: Brett Cannon (bcannon)
Summary: strptime doesn't work with %U

Initial Comment:
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

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-10-19 23:18

Message:
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.

----------------------------------------------------------------------

Comment By: George Yoshida (quiver)
Date: 2004-10-19 22:18

Message:
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

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-10-19 20:50

Message:
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.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-10-19 20:42

Message:
Logged In: YES 
user_id=1038590

I forgot to add that I'm on Linux (Fedora Core 3 Test 1 +
misc updates)

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-10-19 20:39

Message:
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.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-10-19 20:03

Message:
Logged In: YES 
user_id=1038590

Scratch the last comment - I missed the wee_of_year
adjustment at the top of the function.

----------------------------------------------------------------------

Comment By: Nick Coghlan (ncoghlan)
Date: 2004-10-19 19:57

Message:
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.

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2004-10-19 17:31

Message:
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

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-10-19 04:45

Message:
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'

----------------------------------------------------------------------

Comment By: Tony Meyer (anadelonbrin)
Date: 2004-10-18 13:50

Message:
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.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-10-18 11:56

Message:
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 .

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-10-18 09:10

Message:
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 .

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-10-13 11:57

Message:
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

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-10-13 11:57

Message:
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...

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-10-13 11:42

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1045381&group_id=5470


More information about the Python-bugs-list mailing list