I spoke to Matt Mullenweg about this very issue a couple of days ago at WordCamp UK in Cardiff. He said it’s not a problem with the WP core, and if you can’t get pre 1969 dates displaying properly then it’s to do with your host (he seemed aware of the talk around the issue).

Matt mentioned a Benjamin Franklin historical blog powered by WP which works fine, but I’ve been unable to find it. He also said it’s OK to have dates going right back to year zero (pre-Jesus blogging might be a problem, he said).

My site, the Beatles Bible, isn’t displaying pre-1969 dates properly either (see, for example http://www.beatlesbible.com/1965/01/). I used the MySQL query workaround detailed by Hallsofmontezuma in this thread: http://wordpress.org/support/topic/159409
It’s not ideal, however, as it doesn’t seem to allow data formatting (eg 20 January 1965, rather than 1965-01-20 22:00:18, which includes the time down to the second), and the breadcrumb trail is effectively useless (it displays today’s date rather than January 1965).

I’ll give my hosting company a shout and see if they can help.

Interestingly, http://core.trac.wordpress.org/ticket/2149 was recently closed – not because, as Matt claims, the problem is fixed, but because the patch was out of date. It seems odd, possibly unhelpful, to change the status to wontfix/closed rather than needs-patch or even fixed.

Just to update this, I have a dev area on my site with a separate install of WP, which I use to check theme changes, widgets etc in a live environment. I rolled this back to 2.7.1, and the pre-1970 datestamps worked absolutely fine.

So it seems that the problem is a new(ish) one, specific to WP 2.8x.

If anyone cleverer than me can navigate the trac site I’d be grateful if this bug could be reported. Alternatively, if the patch detailed in ticket 2149 could be updated that would be useful.

@gosunatxrea: The link you provided is pretty much the best solution to this problem. Removing those lines from wp-includes/functions.php will prevent dates from looking incorrect in most themes and the WP admin section.

The lines of code that are indicated for removal check to see if the Unix timestamp of a post is less than 0 (that is, before the Unix epoch of midnight, January 1, 1970). If so, the post’s date is automatically set to be the time, right now.

The code block in question is noted as a “sanity check for PHP 5.1.0”, but I don’t see why that’s needed, as to the best of my knowledge, PHP 5.1.0 doesn’t have a problem with negative timestamps.

I started my log afresh, wanting to add content from before 1900 even, hoping that the published date would show up in the URL as well. But I can’t create an archive from before 1969 (and only then because of my server timezone enables a few hours difference from the unix epoch 0).

There seems to be another check for negative dates because I commented out the lines in functions.php, but to no avail.

gosunatxrea’s fix worked for me on a historical blog on FDR’s first hundred days I just set up on Dreamhost that’s running 2.8.4. I’d give you the link, but we literally just put it up, so it’ll be in flux for quite awhile.