I'm glad I have a reflexive "select all and copy" behaviour (born of Radio instability); PyDS just tossed my changes when editing an earlier post. So, here's a refreshed version as a post of its own.
Background thread exception exceptions.ValueError: time data did not match format
D:\Python22\Lib\site-packages\PyDS\Tool.py in thunk
D:\Python22\Lib\site-packages\PyDS\WeblogTool.py in _initthread
D:\Python22\Lib\site-packages\PyDS\WeblogTool.py in renderTimeframeOnline
D:\Python22\Lib\site-packages\PyDS\Tool.py in renderPage  in respond
D:\Python22\Lib\site-packages\PyDS\Tool.py  in getRSSNewestDate
D:\Python22\Lib\site-packages\PyDS\MacrosTool.py in parseTodayFull
D:\Python22\Lib\site-packages\PyDS\strptime.py in strptime
Further investigation reveals that PyDS spends a lot of time converting time tuples to strings and back. And, the reason I'm having trouble with some rendering is that the renderer is bombing out. Which might also explain why I have no RSS.
Hacking in some cheaty code
def parseTodayFull(self, date):
parseFormat = '%a, %d %h %Y %H:%M:%S GMT'
return calendar.timegm(strptime(date, parseFormat))
raise ValueError, 'time data "%s" did not match format "%s"' % (
Background thread exception exceptions.ValueError: time data "Wed, 16 2003 03:57:52 GMT" did not match format "%a, %d %h %Y %H:%M:%S GMT"
I'm bewildered at the design choice. Storing the timestamps as strings is very fragile. PyDS should store timestamps as time tuples or seconds since epoch.
If PyDS must, for whatever reason, store strings, I'd recommend a standard format. For the time being, though, this diff will put the month back and fix RSS as a side-effect.