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: ./test/test_managerlib.py:import xml ./src/subscription_manager/managerlib.py:import xml.utils.iso8601 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.
commit 0bebe4cdfe39700a420f4db821c2c4f61f2d6829 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 that now). 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.