On Nov 11, 7:20 pm, Travis Parks <jehugalea...@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. -- http://mail.python.org/mailman/listinfo/python-list