Do you validate?
At last, the cabal reveals their secret project: a new RSS validator, particularly designed for RSS 2.0. My 2.0 feed does validate, after a bit of wrestling with the dates.
Mark’s Movable Type RSS 2.0 template skates around the problem of producing RFC822 + four digit year dates in MT, by using dc:date (which uses a datetime format that MT has no problem producing), rather than pubDate and lastBuildDate. However, you can produce RFC822 dates, with a little help from the DateTags plugin, as long as your server is in the same timezone as you: <pubDate><$MTEntryDate format="%d %b %Y %H:%M:%S"$> <$MTDaylightOrStandard daylight="PDT" standard="PST"$></pubDate>
will give you RFC822+2.
That ”if you’re in the same timezone as your server” bit is a bummer. Phil, would it be possible to hack the date plugin such that it checked the timezone set in the MT prefs and used that instead of server time? Or does MT not expose that information to plugins?
Timezones are generally supposed to be expressd in UTC (GMT) values. Or you’d need to indicate the timezone you’re using. There’s a macro for it: MTBlogTimezone. Add that within your template’s date formatting and things should be ok.
I should have opened my previous comment with word ’Timestamps’ not ’Timezones’. My template uses:
<dc:date><$MTDate format=”%Y-%m-%dT%H:%M:%S”$></dc:date>
This produces: 2002-09-21T09:13:29-05:00
The W3CDTF spec: http://www.w3.org/TR/NOTE-datetime
Dorothea : I’ll have to look at the whole thing again: I started to look into it when someone asked the question that resulted in the DateTags plugin, but I was way too slow. Offhand, I think the problem is that you aren’t setting a particular daylight/standard regime in Blog Config, only saying roughly how far from UTC you are.
Bill : for producing a W3CDTF date, sure, MTBlogTimezone is fine (probably: I haven’t actually ever looked at how accurate it might be for someone in Arizona with a server in California). For an RFC822 date, though, you’ve got to somehow get from ”-08:00” to a TLA for the timezone.
Damn: can’t anything be simple?
Heh, you want complicated? Try doing date calculations when you’re out of the offset interval. Most systems won’t factor the shift based on the timestamp itself. So if you have a date in the summer that’s using daylight savings time and you try to do a date comparison on it during the winter it will probably get it wrong.
The timezone shifting functions seem to only use the current shift. So my current daylight savings shift of -04:00 will get mangled during the winter time shift of -05:00.
I honestly haven’t checked this in MT. I’m afraid to find out.
You’d think after hundreds of years people would have something finite like TIME figured out.
As for RFC2822 style (which supercedes 822) timestamps it’s perfectly acceptible to use a numeric offset. The 822 format also supported them just fine. No need to use a string format and if a reader can’t handle it then the reader is broken.
As Scooby would say ”ruh-roh”… Movabletype doesn’t do quite what I expected it would for timestamps. I just posted an item on my blog that’s set up as UTC-5. The server in question is running on PDT. The stamping on an item is using my ’local’ time.
I posted, local time at 4:20 pm. Since this is summertime that’s properly expressed as 16:20-04:00. But MT shows it as 16:20-05:00. That’s an hour off. What’s surprised me is that the server is running on PDT (UTC -04:00) and that MT managed to figure out the Universal Time and to somehow transmogrify that into the ’right’ time even though the timezone pull-down is wrong.
Hrm, it got the right time but isn’t expressing the right offset. That’s a fun one. Meanwhile it looks like anyone wanting to do this the ”correct” way has to edit their templates manually.
Can’t be sure but it appears that MT doesn’t handle the timezone properly. During daylight savings time the offset here is -04:00, not the usual -05:00. MT seems to work it’s way into find the ’right’ time but doesn’t alter the timezone string correctly.
And, it looks like maybe maybe maybe I was working around a validator bug by switching to PDT/PST: I knew RFC2822 did numeric offsets, but misremembered RFC822 as not allowing them. However, I can’t get any sort of 822-style numeric offset ( (”+”/”-”) 4DIGIT ) past the validator. You still can’t use MTBlogTimezone, since it looks like 822 doesn’t use a colon between hours and minutes, but even just hard coding -0800 into the template doesn’t validate. If that isn’t a bug, then I’m being even denser than usual.
Phil, you are correct that MTBlogTimezone produces invalid RFC 822-style dates (because of the extra colon). Several people have emailed me bug reports about this, and I’ve triple-checked the spec, and I stand by this statement.
I am more worried about your statement that you can’t get your feed to validate even after hardcoding the timezone. I assume you’re talking about your /index.xml. I just checked, and you appear to have an extra space between the ”-” and the ”0800”. Try ”-0800”.
One of the test cases which passes:
<pubDate>1 Dec 2002 14:20:20 +0000</pubDate>
What value are you trying?
The previous anonymous comment was from me.
I’m trying to figure out how I can make it through the rest of the month without saying anything else stupid, that’s what I’m trying. I don’t know what’s made me unable to get anything right lately, but I’m getting mighty tired of it.
I thought I started off with the right value, ” -0800”, and then when that didn’t work I tried various other things before abandoning it at the unlikely ” – 0800”. But since I just changed it to the right thing and it validated, I must have done something other than right before. Maybe November will be better, but for the meantime you’re probably better off just ignoring me.
Trying to redeem myself, a plugin clone of MTBlogTimezone to produce RFC822 numeric timezone offsets without colons (w00t! I deleted a colon!):
Phil,
I beg to differ – I’d rather have you raise an issue and be ”wrong” initially, than to not raise an issue at all – just look at the discussions you’ve raised recently, that’s great!
Good RSS
Mark Pilgrim and Sam Ruby created an RSS Validator for us to use to validate our RSS feeds, and Bill Kearney was kind enough to host it. Many appreciations, folks. I ran the Validator against my RSS feeds (both Userland
Defuzzing the navel
Phil Ringnalda makes explicit the Movable Type RSS .91 feed issue I to which I just alluded, so yeah. His
Good RSS
Mark Pilgrim and Sam Ruby created an RSS Validator for us to use to validate our RSS feeds, and Bill Kearney was kind enough to host it. Many appreciations, folks. I ran the Validator against my RSS feeds (both Userland RSS and RDF/RSS feeds) per Mark’…
Meet me down at the pubDate
Futzing about with my RSS 2 feed, I discovered the mind-numbing fact that Movable Type can’t output a valid pubDate…
Thanks, Phil
In response to my previous entry, Phil Ringnalda posted a helpful comment. However, on reflection my problem is bigger than I thought, because Israel’s timezone is an elusive creature.
The RSS Vet
So now I have an RSS feed. There’s really no reason it took so long for me to get one after switching to Movable Type. I just don’t care much about RSS, so it was never a priority. And I…