Re: [syndication] Re: Aggregating your global content output into your blog

["Bill Kearney" <ml_yahoo@ideaspace.net>]

> Not automatically... the extra steps are trivial (strip the "T",
> snip the offset), but they're there. The real annoyance is handling
> feeds that stray from common practice, like <dc:date>s that omit the
> offset. The additional parsing code starts to stack up.

It's especially annoying when the specs aren't followed.  Snipping the offset?
Without processing it as a valid directive to adjust the time?  That'd be bad.
As for uses that omit the offset, those are to be consider UTC times, correct?

> Obviously, that's a problem with <pubDate>, too... Plastic uses a
> non-POP date format in its <pubDate>, for example. It just so
> happens that ParseDateTime() handles most of those aberrations
> transparently, so I don't have to go to any extra effort with their
> feed.

Things that 'transparently' fix these subtle abberations are often a BIGGER
problem than the abberations themselves.  Better to expose them for the mistakes
they make rather than leave them stand as bad examples.  As has been seen in
most RSS-related errors, once informed of the correct method most developers
have been readily able to implement fixes.  It doesn't seem unreasonable that
Macromedia couldn't be 'encouraged' to address these limitations.  That doesn't
help a live site now, of course.

> > Near as I can tell this would be a simple matter of using
> DateConvert
> > to make a UTC time and then using LSDateFormat and LSTimeFormat to
> > concatenate the string.
>
> Oh, *creating* a <dc:date> is no biggie... it's simply that I
> instinctively hesitate before creating dog food I wouldn't want to
> eat. :) But just for the hell of it, I added <dc:date> to both the
> forum feeds and the default RSS template for new blogs a few minutes
> ago.

I can't argue against the logic of 'eating ones own dogfood' but in this case
it's not that good an excuse.  There's a saying that goes 'be liberal in what
you consume but conservative in what you create'.  Using 822 style timestamps
works fine if you're within one of the known 'alphabetic' timezones AND you
understand what's going on.  That combination isn't seen the world over.  Yes,
this should be old hat by now.  But if you're going to follow up to date
standards, why not make use of a timestamp format with a lot less ambiguity and
room for errors?

-Bill Kearney