When "return" really does mean "return"
Aug. 18th, 2007 04:23 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
afuna_archiveHahaha, I feel immensely silly right now. I've been staring at parsefeed.pl, trying to figure out how two pieces of date-parsing code were related to each other, and I only just realized that one is Atom-specific, the other RSS-specific, and that if you're in an Atom feed, which is what I needed to look at, then you return before you reach the RSS-specific parsing code.
(I thought that there would be another module for parsing RSS, just as there was for parsing Atom and that a certain block was being called when parsing both RSS and Atom *facepalm*)
I've been looking at this (dumbly) since last night.
On the good side, the reason I couldn't find where certain attributes were being handled is because it looks like these attributes aren't being handled at all (the attributes in question being
I wonder why the Atom parser doesn't use
Must recheck my results in this request later, but it looks right to me. If it pans out, then RT.
(I thought that there would be another module for parsing RSS, just as there was for parsing Atom and that a certain block was being called when parsing both RSS and Atom *facepalm*)
I've been looking at this (dumbly) since last night.
On the good side, the reason I couldn't find where certain attributes were being handled is because it looks like these attributes aren't being handled at all (the attributes in question being
_atom_updated and _atom_published; only _atom_modified and _atom_created are being processed).I wonder why the Atom parser doesn't use
w3cdtf_to_time. Are Atom feeds guaranteed to more strictly follow a certain format?Must recheck my results in this request later, but it looks right to me. If it pans out, then RT.
