Localized RSS Date Time...

by Phil 'iwonder' Guerra
--- (Mission, KS). Not sure why folks want to change the pubDate format given in a newsfeed. I have nothing but trouble when I try to base anything on pubDate. I can understand the desire to show feeds with localized date/time, but seems like a whole lot of trouble to go through. My experience with most feeds generated is that they don't even reflect correct information in about 80% of the usage I've seen. The discrepency usually can be attributed to developers not understanding how to correctly use date/time fields and convert them, and the further complication of date/times being formatted in databases based on the server date/time setup, which may not be correctly setup or maintained.

It's really puzzling to me how RSS specs decided to use the RFC822 date/time format in the first place. This was a standard developed for first gen email text messages. Peter's correct in that it was an American originated spec, but it did have a group of international folks working on it, which is why the format doesn't even match American date formats either. Now to really confuse matters, the RFC822 spec is really obsolete, the newer RFC2822 is the defacto standard. So, why in the world do we not use it? Well, it isn't all that much better for this type of usage, folks.

Perhaps a better standard would be ISO8601 (see a Wiki entry here. If you still are not totally confused, and want to press further, I suppose you are just bent that way, and since you are using MS prodcuts with DotNetNuke, you could prolly find a way to do this in the News module, since it's rewritting the incoming news source anyway. However, that brings us back to the lack of folks using any standard to start. Any code fix requires some kind of 'rule' to fallback on, and with many news feeds, there just isn't any reliability. Also, what do you suggest is used for the default language? Is it the portal setting for preferred language, the host server setting for language, or the end-user's machine language setting? Those questions have never been answered in the core DotNetNuke code. I know because, I tried to get folks to make a decision on it, and never got any DNN Core Team members to attach enough significance to it to make it happen. It's still not resolved in the DNN.

In fact, to be fair, it's not really resolved in Microsoft's world either. Yes, I know about the Olson timezone, tz database in use on Unix, Linux, and other implementations. I am a member of the tz mail list, and over the years, even that solution goes through incredible changes in year, almost daily. I've come to the conclusion that until the world comes under one umbrella, there is not going to be a solution to please everyone. Although, if you need me to vote, I'd say hitch your wagon to the tz database if you can, at least it has provision for being used for historical context, supported by users throughout the globe, not just in Redmond.

Now, you can change the format using XSL, but it's a real chore to provide a solution that's universal and fully globalized. Most solutions are going to be local solutions as far as I can tell. I've done a bit of that stuff, but reverted back to not caring about it because most feeds don't always give you pubDate in the rfc822 format, and trying to figure out universal routines to deal with all the variances of gloablized date/time formats is difficult to say the least. So, I just take it as it is - much like the content in a feed.

I don't even like to validate the pubDate format because I'd rather worry about getting the content than stressing over whether the pubDate is valid and miss displaying the content. Maybe I'm funny that way, but my usage of feeds is not based on pubDate, and if I choose to cache, I think the better approach would be to simulate a ttl element based on the date/time I pulled the feed originally, if one is not available. I'd use whatever is there, if easily parsed, so I can display the pubDate as given, and still have control over timing for feed retrieval and display. Just my thoughts...