How hard is it for someone to PROPERLY use the ISO-8601 long date format?

I've spent the entire afternoon trying to adjust for the offset specified in the >cap:sent< field of http://www.nws.noaa.gov/alerts/in.cap, and I just now figured out that a) they're not offsets from UTC, and b) the times aren't in the format I was told by the guy from the National Weather Service who is in charge of the CAP feeds.

Why is this a big deal? Let me explain...

Indiana is at the tip of "Tornado Alley", here in the USA. Usually, between about the middle of April and the beginning of October, we get some spectacular storms. Since I am not always watching TV, listening to the radio, or looking at the Storm Prediction Center website, I decided to come up with a way to get accurate weather alerts on my cell phone.

Initially, I was going to try to muddle through the IWIN reports, but a friend found the XML feeds that the NWS provides. Since PHP has some rather useful extensions to parse XML, this data format made the job quite a bit easier... Or so I thought.

Last year, I had a hacked-up version of my alerts system running. It worked but was prone to errors, so I decided back in January to rewrite it before the storm season hit.

I thought I had it all working, until today when I got one of the first alerts of the season. Everything was legible, I knew what the condition was, where it affected, but I didn't know when it was effective or when it expired. Even though it had timestamps to go by, the times related to the alert were a mystery.

I dug into the code to try and find a way to compensate for the difference in time zones, and I was greeted by the beginning of a very stressful road. Now, I think I've hit a dead end.

Earlier this month, I e-mailed Robert Bunge, the NWS employee I mentioned earlier, about the timestamps.

I said..

I have been working rather dilligently on updating my application with the information you have provided, however, there are a couple hurdles that I am having trouble getting over. The first and foremost issue is the timezone for each alert. I assume the alerts are stamped with UTC times, but since my system will be used by the general public, I can't work from that assumption. I need to know for certain, specifically in the us.cap file, what time zone the cap:effective and cap:expires are marked in. If this time is not in UTC, I would like to suggest that it be considered to either migrate to UTC, or provide a means of identifying the alert's time zone in relation to UTC.

Seems reasonable, I thought. Shortly after that, I got this response:

They are local time. There is long (about a hundred years, worth) of history behind why we do this and I actually don't pretend to understand it all! I do see us moving to UTC in the future, but I think it's a ways off (as in several years). Id'ing the actual time zone is a big problem, specially in places like Indiana.

Great... That's a pain to work with. Today, though, I saw that the very first timestamp in the CAP feeds has an offset from GMT/UTC... Or so I thought. After spending a couple of hours working with it, I found that that offset is something to do with the local time zone, which (as Bob said) is a problem. The majority of Indiana is in CST, but the few of us in about 10 counties get to deal with Daylight Savings Time, puting us another hour behind the rest of the state. This time of year, that isn't an issue. For any system that makes use of the CAP feeds to be effective, they need to be able to identify the PROPER local time zone in relation to the time zone of the feeds.

I've decided to just give up and forget about it until the National Weather Service gets something done with this issue. I highly encourage you to post a comment with your agreement to this issue, so I will have a little bit of leverage to get them to change the feeds to use UTC, rather than having to jump through hoops to figure out the time zone.