Description of problem:
For Fedora 18 we're trying to get rid of PyXML due to a cobination of it being dead upstream for many years and that when it's installed, the python stdlib overwrites its own xml module with PyXML. This combination leads to errors because PyXML's code is older and contains bugs that have been fixed in the stdlib.
I've taken a look at why subscription-manager has a dependency on PyXML and it looks like it is due to one usage of the xml module for parsing dates:
Can this functionality be ported to another library? Perhaps one of the ones on this page: http://wiki.python.org/moin/WorkingWithTime
If I understand what the code in managerlib.parseDate() is doing (and I might not!) I think it could be replaced with one call to dateutils.parser.parse(date). dateutils handles both timezones and overflow itself (The behaviour on 32 bit systems with overflow is different, though. The test case ends up with parsed.year == 9999, parsed.month = 9, parsed.day = 6 on both 32 bit and 64 bit systems with dateutils while with xml.utils.iso8601 the date overflows and is set to the default value.)
I've been asking around, I believe this was done as it was the only working date formatter on EL5. We're going to try to address it in our next sprint so within the next few weeks.
Author: Adrian Likins <alikins>
Date: Mon Oct 8 14:14:31 2012 -0400
844072: remove use and dep of PyXML
PyXML is deprecated in Fedora, so remove it.
Only use of pyxml was for it's iso8601 date parsing,
so replace it's usage with dateutil (and require
dateutil.parser.parse() behaviour is slightly different,
especially for year 2038 issues. Dateutil handles this
better at least till year 9999, so update test cases
for those cases.
Note: previous parseDate was actually incorrect for cases
where the server returned iso8601 dates with a tz (instead
of UTC). This doesn't seem to matter because the server
always returns iso8601 dates with UTC tz. Updated
test cases for this scenario.
Looks good to me. Closing this Rawhide.