msg62082 - (view) |
Author: Ralf Schmitt (schmir) |
Date: 2008-02-05 23:12 |
xmlrpclib uses datetime.strftime which cannot handle dates before 1900. this patch adds a custom date formatting function, which does not have this restriction. It also contains 2 additional unit tests, which both fail with the unpatched version. |
|
|
msg62092 - (view) |
Author: Christian Heimes (christian.heimes) *  |
Date: 2008-02-06 12:05 |
Does your patch also work on systems which don't allow negative values for time_t? |
|
|
msg62094 - (view) |
Author: Ralf Schmitt (schmir) |
Date: 2008-02-06 12:18 |
Well, all it basically does is changing calls to obj.strftime to a custom string formatting function (where obj is a datetime.datetime, datetime.date or datetime.time). These strftime calls are made during object marshalling. So, all the objects to be marshalled are created by the program itself. The datetime module allows those dates to be created, so I think it should be safe. The unmarshalling code did not change, so it's possible to receive a date before 1900, but not to send it back... But to answer your question. I don't know, I don't even know a platform, which use an unsigned time_t. |
|
|
msg62518 - (view) |
Author: Ralf Schmitt (schmir) |
Date: 2008-02-18 07:58 |
http://bugs.python.org/issue1777412 describes the cause of this issue (i.e. strftime not being able to handle years before 1900). |
|
|
msg62810 - (view) |
Author: Ralf Schmitt (schmir) |
Date: 2008-02-23 21:10 |
Attaching an updated version of the patch against trunk revision 61011. |
|
|
msg65608 - (view) |
Author: Ralf Schmitt (schmir) |
Date: 2008-04-18 09:33 |
guido says it's ok to fix the issue in xmlrpclib only: http://mail.python.org/pipermail/python-dev/2008-April/078396.html I'm also attaching a dummy.diff in order to have a patch keyword... If someone is willing to commit this, I'll check if it still applies to trunk and maybe update the diff. |
|
|
msg65611 - (view) |
Author: Skip Montanaro (skip.montanaro) *  |
Date: 2008-04-18 13:00 |
working on it |
|
|
msg65623 - (view) |
Author: Skip Montanaro (skip.montanaro) *  |
Date: 2008-04-18 20:36 |
Checked in on trunk as r62378. Will let the normal 3.0 merge process suck it over to the py3k branch. |
|
|
msg65644 - (view) |
Author: Ralf Schmitt (schmir) |
Date: 2008-04-20 11:52 |
Skip, thanks for handling this. |
|
|