TypeError while running bzr selftest --subunit | subunit2junitxml

subunit generates UTC aware timestamps, and junitxml doesn't grok that because the types are (IMO wrongly) incompatible.

I think this is a significant and imprtant bug to fix, but I want to get another subunit release done so it may be a little bit before I get to this.

I think a reasonable way to fix this would be to:
 - get utc aware timestamps from utcnow

and leave it at that for now.

Just noting that I just ran into this. We'd like to start using hudson instead of buildbot for babune, so I figured I'd try hooking up some of the Windows bits. However, any testing I've done always fails with this.

I don't quite understand why, given that the code I see in junitxml is:
def _now(self):
    if self._set_time is not None:
        return self._set_time
    else:
        return datetime.datetime.utcnow()

Going further, I don't see why utcnow does anything

from datetime import datetime

n = datetime.now(); u = datetime.utcnow()
n - u

datetime.timedelta(-1, 64800)

So either now and utcnow both return the same (unaware/aware) timestamps, or the subtraction is possible...

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()

     def _duration(self, from_datetime):
- 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.timedelta(-1)
         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:
http://docs.python.org/library/datetime.html

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.