So I did some debugging with this patch:
=== modified file 'junitxml/__init__.py'
--- junitxml/__init__.py 2009-11-19 08:33:25 +0000
+++ junitxml/__init__.py 2009-12-10 05:06:24 +0000
@@ -53,7 +53,12 @@ self._test_start = self._now()
It looks like making datetime "tizmezone" aware is asking for trouble:
For applications requiring more, datetime and time objects have an optional time zone information member, tzinfo, that can contain an instance of a subclass of the abstract tzinfo class. These tzinfo objects capture information about the offset from UTC time, the time zone name, and whether Daylight Saving Time is in effect. Note that no concrete tzinfo classes are supplied by the datetime module. Supporting timezones at whatever level of detail is required is up to the application. The rules for time adjustment across the world are more political than rational, and there is no standard suitable for every application.
My guess is that the easiest fix is to ignore TZ info in subunit... I guess we could look at the bzrlib code to see how we get timezone there. We do:
if t is None:
t = time.time()
offset = datetime.fromtimestamp(t) - datetime.utcfromtimestamp(t)
also note that it just gets uglier from there. But I'm associating a branch with this bug. It at least makes the test suite run and generate xml. Even if the code makes me cry a little bit inside.
So I did some debugging with this patch: __init_ _.py' __init_ _.py 2009-11-19 08:33:25 +0000 __init_ _.py 2009-12-10 05:06:24 +0000
self. _test_start = self._now()
=== modified file 'junitxml/
--- junitxml/
+++ junitxml/
@@ -53,7 +53,12 @@
def _duration(self, from_datetime): timedelta( -1)
- delta = self._now() - from_datetime
+ try:
+ delta = self._now() - from_datetime
+ except TypeError:
+ n = self._now()
+ print n, self._set_time, from_datetime
+ delta = datetime.
seconds = delta.days * 3600*24 + delta.seconds
return seconds + 0.000001 * delta.microseconds
And looking at the output, the only line that got a weird time was:
<testsuite errors="0" failures="0" name="" tests="149" time="-86400.000">
And I think that is because _run_start is the only call that hasn't had a 'time' come in from the data stream yet.
As near as I can tell the problem isn't being *utc* aware, but being *timezone* aware. And trying to track that down is giving me headaches.
Namely, 'datetime. datetime. now()' takes a 'tz' object. And I can get a tz object from 'datetime. tzinfo( )', but once I've done that I get an exception:
Looking here: docs.python. org/library/ datetime. html
http://
It looks like making datetime "tizmezone" aware is asking for trouble:
For applications requiring more, datetime and time objects have an optional time zone information member, tzinfo, that can contain an instance of a subclass of the abstract tzinfo class. These tzinfo objects capture information about the offset from UTC time, the time zone name, and whether Daylight Saving Time is in effect. Note that no concrete tzinfo classes are supplied by the datetime module. Supporting timezones at whatever level of detail is required is up to the application. The rules for time adjustment across the world are more political than rational, and there is no standard suitable for every application.
My guess is that the easiest fix is to ignore TZ info in subunit... I guess we could look at the bzrlib code to see how we get timezone there. We do: fromtimestamp( t) - datetime. utcfromtimestam p(t)
if t is None:
t = time.time()
offset = datetime.
also note that it just gets uglier from there. But I'm associating a branch with this bug. It at least makes the test suite run and generate xml. Even if the code makes me cry a little bit inside.