time.strftime in 2.4.1 claims data out of range when not

[Sheila King]

I have a web app that has been running just fine for several months under
Python 2.2.2.

We are preparing to upgrade the server to run Python 2.4.1.

However, part of my web app is throwing an error on this code (that has
previously worked without exception):
Traceback (most recent call last):
15L


I don't see what parts of the date that I have submitted to strftime are out
of range?

Also, the phrasing of the error message is a bit odd?
"day of year out of range"

I'm not sure what the
day of a year

would be???

Sheila King
http://www.thinkspot.net/sheila/

 

[Brian van den Broek]

Sheila King said unto the world upon 2005-04-22 02:45:

I have a web app that has been running just fine for several months under
Python 2.2.2.

We are preparing to upgrade the server to run Python 2.4.1.

However, part of my web app is throwing an error on this code (that has
previously worked without exception):



Traceback (most recent call last):


15L


I don't see what parts of the date that I have submitted to strftime are out
of range?

Also, the phrasing of the error message is a bit odd?
"day of year out of range"

I'm not sure what the
day of a year

would be???

Sheila King
http://www.thinkspot.net/sheila/

The day of the year is the ordinal number of the day, counting from
Jan. 1st. So, Feb. 1st is the 32nd day, Dec 31 the 365/6 (depending on
leap year).

The docs for the time module indicate that the 8th (counting from 1)
position of a struct_time is the day of the year, and that it can
range from 1-366. So, naturally, the 0 value in your 8th position is
the problem.

That does leave the mystery of why your code worked on 2.2.2; I've no
idea. The docs do seem to indicate that there were a number of changes
at 2.2, though.

Best,

Brian vdB

 

[Raymond Hettinger]

[Sheila King]

I have a web app that has been running just fine for several months under
Python 2.2.2.

We are preparing to upgrade the server to run Python 2.4.1.

However, part of my web app is throwing an error on this code (that has
previously worked without exception):

Traceback (most recent call last):

15L

From the docs for time.strptime:
"The default values used to fill in any missing data are (1900, 1, 1, 0, 0,
0, 0, 1, -1) ".

So, you could change the offending code line to:'2005-05-15'

Since the rules for handling missing, inconsistent, or out-of-range tuple fields
are not defined, even that revision has some risk. To future-proof the code,
use strptime() to generate a well-formed time tuple:
'2005-05-15'

This somewhat circular technique sticks with the documented API but allows you
to access all of the time module's options (like accessing the locale's names
for days of the week and months of the year).


Raymond Hettinger

 

[Kent Johnson]

Since the rules for handling missing, inconsistent, or out-of-range tuple fields
are not defined, even that revision has some risk. To future-proof the code,
use strptime() to generate a well-formed time tuple:


(2005, 5, 15, 0, 0, 0, 6, 135, -1)


'2005-05-15'

or use datetime.date which only needs y, m, d:
'2005-05-15'

Kent

 

[Tim Peters]

[Sheila King]

I have a web app that has been running just fine for several months under
Python 2.2.2.

We are preparing to upgrade the server to run Python 2.4.1.

However, part of my web app is throwing an error on this code (that has
previously worked without exception):

Traceback (most recent call last):

15L

I don't see what parts of the date that I have submitted to strftime are out
of range?

Also, the phrasing of the error message is a bit odd?
"day of year out of range"

That was explained already, so I won't again. The NEWS file for
Python 2.4a1 explains why:

"""
- time.strftime() now checks that the values in its time tuple argument
are within the proper boundaries to prevent possible crashes from the
platform's C library implementation of strftime(). Can possibly
break code that uses values outside the range that didn't cause
problems previously (such as sitting day of year to 0). Fixes bug
#897625.
"""

See the referenced bug report for examples of platforms whose
strftime()s crashed the app, or just returned utter gibberish, when
passed senseless values. Python's strftime wrapper now verifies that
all passed-in values are in range, no longer trusting the platform C's
strftime() to do error-checking.

 

[Moderator, k12.ed.math]

Hello,

Thank you to all who replied. Yes, obviously the extra values I'm passing are
out of range, such as the ordinal day-number of the year. Oy.

I've been having a number of issues with switching from 2.2.2 to 2.4.1 and
last night when I started trying to address this problem (at a late hour) I'm
afraid my thunker sure wasn't thunking.

I like the datetime.date suggestion best, probably.

Again, thanks, and this will help me to get through this niggle...

Sheila King
http://www.thinkspot.net/sheila/