Date Time Best Practices & RSS

I quickly recognized many of my pet peaves with DateTime problems from the recent MSDN article, "Coding Best Practices Using DateTime in the .NET Framework".

The single biggest offender in the category of "inaccurate DateTime usage" is RSS feeds!

Today, several popular & commonly used RSS class libraries introduce inaccurate dates due their impenetrable API's, and the way they are consumed by developers. The main cause is that the RSS specification requires dates to be expressed as an RFC 822 date/time.


Mon, 11 Mar 2004 10:42:02 CST

This is just a different string-expression for a date/time that includes the Timezone. This isnt a problem in itself but can become a problem because most RSS library API's use a standard DateTime type, but use parameter names such as "pubDate" which doesnt explicitly tell the developer that RSS date-times must be timezone-specific. So, after the RSS feed is created, and output as XML, it takes a keen eye to notice that the DateTime says it is in GMT, but in fact is incorrect to the tune of 6 hours (this .Text weblog engine is a perfect example). This happens because the .NET Framework doesnt provide a built-in converter for RFC822, so RSS libraries often use a format-string that forces the timezone to GMT or UT:

private const string DateTimeFormatString = "ddd, dd MMM yyyy HH':'mm':'ss 'GMT'";
instead of:
private const string DateTimeFormatString = "ddd, dd MMM yyyy HH':'mm':'ss zzz";

The RSS Library creators will simply say "Its the developer's fault for not converting to GMT", others will say "Its the .NET Framework's fault for not supporting RFC822". Both are true, but it is equally the fault of the RSS API implementation for not leading the eager developer to the correct implementation. As a result, most developers will start by creating a new instance of an RSS feed and begin adding new RSSItems based upon their local data-source without regard to timezone. Frequently this local data source is based upon local time, not GMT or UT (Universal Time) therefore you end up with skewed datetimes.

So, I would just like to add a Best Practice of:

Always make your DateTime variable-names explicitly state the DateTime type expected. For example, use "pubUTDate" or "pubGMTDate" instead of just "pubDate" for your parameter or property name. This will make your API's behavior much more transparent when dealing with DateTime values. Alternately, for RSS feeds, you should consider names such as Rfc822Date. Perhaps someone could do the work of creating a new Rfc822Date formatter, converter, and type to simplify this further.


  • Excellent.

    I recall looking at RFC 1123 a while back, but hadnt seen the connection to RFC 822. That definitely looks like the preferred implementation.


  • Hi,

    Maybe a dumb question, but how to parse this kind of date time (string) values?

    To write i use dt.ToString("r"), it works... but i can't parse real rfc822 date time's like

    Tue, 09 Mar 2004 08:59:02 -0800

    Tue, 09 Mar 2004 08:59:02 EST

    with the build in .NET DateTime struct.



  • I'm still working on a good reply to your question, but frankly, I havent tried parsing an RFC822 datetime string yet...will let you know soon (hopefully)

  • I've been using DateTime.ToUniversalTime.ToString("r"). Looks good here, why should I use a custom formatter?

Comments have been disabled for this content.