xmlrpclib date times and a trailing Z

[Travis Parks]

On Nov 11, 7:20 pm, Travis Parks <jehugalea... at gmail.com> wrote:
> I am trying to connect to Marchex's a call tracking software using
> xmlrpclib. I was able to get some code working, but I ran into a
> problem dealing with transfering datetimes.
>
> When I construct a xmlrpclib.ServerProxy, I am setting the
> use_datetime flag to indicate that I want to automatically convert
> back and forth between date times in the datetime library.
>
> I have a working version that doesn't use this flag, and I have to
> convert from the xmlrpclib.DateTime type to the datetime.datetime type
> manually, via string parsing.
>
> The thing is, Marchex's API returns date's with a trailing Z, after
> the time component. I did some research and this is supposed to be an
> indicator that UTC was used. However, it doesn't seem like the
> xmlrpclib likes it very much.
>
> It looks like it is using this code internally: time.strptime(data, "%Y
> %m%dT%H:%M:%S")
>
> This code doesn't look like it handles time zones at all. I guess, is
> there a way to tell xmlrpclib to include time zones when parsing date
> times?
>
> Thanks,
> Travis Parks

I did some chatting on IRC and it seems that the date/time format is
not very well defined in XML RPC specs. So, basically, Marchex is
using a format that the XML RPC library doesn't support. Strangely,
Marchex supports incoming dates with the format yyyyMMddThhmmss. It
just spits dates back out with yyyy-MM-ddThh:mm:ssZ. The ISO8601
standard seems to be used a lot, so it is surprising the library
doesn't try multiple formats, at least.

I find it strange that the library, in light of the fact that date
formats aren't standardized, doesn't provide the ability to configure
this. I also find it strange that the library doesn't incorporate
Basic Authentication using urllib2, but instead rolls its own method
of putting username:password@ before the netloc.

I wish Python's libraries acted more like an integrated framework than
just unrelated libraries. I suppose I am spoiled from years of working
with all-in-one frameworks managed by a single group. That is not the
way C/C++ works or how Linux works. The power generated by using a
conglomeration of unrelated libraries is indisputable, even if it can
be a productivity killer and just plain confusing.