ValueError raised when due date for milestone is too large

[vbs]

Trac raises ValueError when you assign date from year 2038 onwards to milestone due date (*). This exception is never catched.

The problem is with this two lines, maybe more:

• source:trunk/trac/ticket/model.py@5378#L590​
• source:trunk/trac/ticket/model.py@5378#L679​

(*) As is stated in Python documentation:

fromtimestamp() may raise ValueError, if the timestamp is out of the range of values supported by the platform C localtime() or gmtime() functions.

---

Sorry for my bad english. I'm a foreign speaker.

[Christian Boos]

#5403 was closed as duplicate.

[osimons <simon-code@…>]

#3672 closed as duplicate.

[osimons]

The 'Versions' admin page shows the same behaviour on such dates.

We need at least provide standard error pages instead of displaying the traceback.

[osimons]

Patch that ensures that we can convert to and from timestamp before accepting input as a valid date.

[osimons]

Think I found it. What happens is that we:

• Parse the date correctly
• We convert it to a timestamp
• And we save it to the database

Problem is, as you correctly noticed, that it cannot be converted back if the underlying C localtime() and gmtime() functions use 32-bit ints for counting seconds since epoch. That puts the limit some time in 2038.

I've made a patch to the Trac parse_date() metod that basically does the conversion to and from timestamp, and raises an error if the date does not pass this test.

Please test t5322-r6317-date_valuerror-a.diff​.

[Christian Boos]

Replying to osimons:

I've made a patch to the Trac parse_date() method that basically does the conversion to and from timestamp, and raises an error if the date does not pass this test.

Great idea! That seems very robust this way. However IIUC, the error we trap in this case is not due to a wrong format, but to an out of bound condition, so the error message should rather indicate that.

[osimons]

Fixed the error message a little, and applied in [6318].

Closing.