Y2038 Feed
So, I’m curious, how many parsers/feed readers show an incorrect date for this feed or just blow up for that matter?
So far in my testing, NetNewsWire has been the only parser that correctly displays the date given in the feed. FeedTools can’t parse the date and reverts to the current date and time instead. So does Google Reader and Bloglines, as well as most of the online feed readers I tried it out with.
The Feed Validator does helpfully warn me of an “implausible date”, but the feed is perfectly valid Atom 1.0, so far as I can tell.
I’m honestly not too worried about the issue of parsers not being able to handle the concept of 2038 when it roles around. By 2038, the concept of feeds will likely seem utterly obsolete. But I can’t help but wonder if some parsers will end up tossing an exception on this feed. I couldn’t find anything in Mark Pilgrim ’s UFP test suite for dates being out of range. The largest date among the tests seems to be some time in 2004.
“Implausible date” simply means that the date is in the future – in other words, the date is syntatically correct, but unlikely to be accurate.
Snarfer displays the date for the entry as 1/20/2110. I’m assuming that’s what it’s supposed to do.
UFP 4.0.3 doesn’t parse this date correctly. You can track this as bug 1395690.
Basically, I believe what’s happening with FeedTools (and probably any other parser that breaks) is that the date is too big to fit if it’s expressed as a time_t data type. Rollover occurs January 28th, 2038, IIRC.
Thanks for the explanation Sam.
Incidentally, this bug is also why Google has their “non-expiring” cookie set to expire in 2038 instead of the year 3000. (Disclaimer: I couldn’t care less about a non-expiring cookie.)
I investigated this a bit further and discovered that Python relies on a standard C library to handle all the time stuff, and the C library stops at 2038.
http://docs.python.org/lib/module-time.html
The third-party mxDateTime module claims to be year-2038-compliant.
http://www.egenix.com/files/python/mxDateTime.html
It appears to be open source (GOD DAMN IT WHY DOES EVERYONE NEED TO INVENT THEIR OWN LICENSE). It’s not listed at OSI, nor is it mentioned on FSF’s license page, but it’s been in Debian main for long enough that someone probably would have notice if it weren’t open source.
Anyway, it’s not worth a hard dependency, but I could add a weak dependency that would use mxDateTime if it were available.
Cool, that seems like a sensible plan. I wonder if there isn’t something similar for Ruby.
i posted about this a few months ago take a look. i ran into the issue when working with different chat applications. http://www.skattertech.com/2005/07/y2k38-bug-has-started/
Leave a Response