Implausible Date

“Saturn”: The Feed Validator clearly isn’t updated with the new Daylight Saving dates, since it comes up with “implausible date” for every feed I test...

Engadget seems to have “sprung forward” but still be on EST.


Incidents like this just make it more and more obvious that you have employed the right solution for all time zone-related matters, Sam.

Hovering over the date above I see that you are still providing an unadjusted GMT time to us, which we are all seeing as our local times.

Meanwhile, your post has reminded me that I need to change my time zone for Daylight Saving Time on all of my WordPress weblogs.  I can’t believe I still need to do this.

Posted by Mike Mariano at

Mike, I wouldn’t go so far as to say that Sam “employed the right solution for all time zone-related matters” — unless you want to add “in the past”.  Sorry to be off topic, but I’d like to explain.

Consider the problem of scheduling an event sometime in the future.  Anyone around the world might want to go to this event (say, a conference). How do you create an iCalendar file for someone in EST  (GMT -5), who wants to attend an event in CET (GMT +1)?  The Principle of Least Surprise suggests that if the event starts at 9am, then they want to see it in their calendar program at 9am, timezone be damned.  If you encode the date/time info as GMT, I believe that what programs like Outlook will do is display this event as happening at 3am EST, which is technically correct but confusing.

I should probably blog about this problem in more detail and see what you guys have to say about it. :)

Posted by roberthahn at

It also seems to claim that “2008-03-16T18:51:34.000000+0000” isn’t a valid RFC-3339 date-time.

Posted by Toby Inkster at

Seems to claim?  From the spec:

time-numoffset  = ("+" / "-") time-hour ":" time-minute
Posted by Sam Ruby at

Add your comment












Nav Bar