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.

Title: xmlrpclib cannot send datetime objects with dates before 1900
Type: enhancement Stage:
Components: Library (Lib) Versions: Python 3.0, Python 2.6
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: skip.montanaro Nosy List: christian.heimes, schmir, skip.montanaro
Priority: normal Keywords: patch

Created on 2008-02-05 23:12 by schmir, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit
xmlrpc_date_before_1900.txt schmir, 2008-02-05 23:12 patch against release25-maint
xmlrpc_date_before_1900_r61011.txt schmir, 2008-02-23 21:10 updated version. patch against trunk r61011
Messages (9)
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) * (Python committer) 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, 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 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:

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) * (Python triager) Date: 2008-04-18 13:00
working on it
msg65623 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) 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.
Date User Action Args
2022-04-11 14:56:30adminsetgithub: 46298
2008-04-20 11:52:03schmirsetmessages: + msg65644
2008-04-18 20:36:29skip.montanarosetstatus: open -> closed
resolution: accepted
messages: + msg65623
2008-04-18 13:00:00skip.montanarosetassignee: skip.montanaro
messages: + msg65611
nosy: + skip.montanaro
2008-04-18 09:33:58schmirsetmessages: + msg65608
2008-02-23 21:10:44schmirsetfiles: + xmlrpc_date_before_1900_r61011.txt
messages: + msg62810
2008-02-18 07:58:05schmirsetmessages: + msg62518
2008-02-06 12:18:44schmirsetmessages: + msg62094
2008-02-06 12:05:23christian.heimessetversions: + Python 3.0, - Python 2.5
nosy: + christian.heimes
messages: + msg62092
priority: normal
keywords: + patch
type: behavior -> enhancement
2008-02-05 23:12:36schmircreate