This is one of a number of reasons -- but the most important one -- that we cannot switch to PHP 5. Apparently this guy can't either, or he has and he's discovered the bug too late. 
Is there not a work-around for this in PHP 5 -- one that doesn't involve changing massive amounts of logic? You guys usually do a great job. This looks like it slipped through the cracks.

Not understanding things doesn't make the logic bogus. For example, Unix timestamps (like the big fancy number that you posted) are always in UTC (seconds since 1970-01-01 00:00 UTC). In case you have a timezone selected, it might shift to/from DST during your "calculation" and it fucks up because you're doing it wrong. For me, the code you gave shows:

$ php -r 'echo date("M j, Y H:i", (1237787999 - 86400));'
Mar 22, 2009 06:59

which is perfectly okay. So two things:
1. Set the proper time zone
2. Use proper code like:

<?php
$d = date_create( "@1237787999" )->modify( "-1 day" );
echo $d->format( 'M j, Y H:i' ), "\n";
?>

3. If you really want to know how all this stuff works: http://phpdatebook.com

Thanks for your comment and the link. "Bogus" may be the wrong word for my description of the logic, but it is also wrong for this status; for many people this was an undesirable (and unneeded) change. There are probably billions of lines of legacy code that stored dates with previous versions of PHP (in whatever time zone) and people expected to get those same dates back with PHP 5. That is not what happens. Second, and perhaps more to-the-point, MySQL never fails to return the correct date based on my time zone. Since PHP and MySQL have long been linked as the ideal developer solution, one would not expect them to return different results for dates when both are set to the same time zone. And I still object to the absence of a simple switch that allows the developer to turn DST off. 
In the meantime, MY work-around is to set the date_timezone setting in the php.ini file to "America/Belize" which in effect maintains my timezone at CST year 'round. This yields compatibility with the dates that are *already stored* in our system and which I'm not willing to convert because I have bigger things to do. Most countries nearer the equator don't need to use DST. So my rec for people bitten by this DST thing is to find a country due south of you that doesn't use DST. Then use that timezone setting.
It is apparent from reading many other posts on this (which you've closed) that you do not want to, or cannot decide how to, deal with it. Looking at it from a strictly academic standpoint, I'm sure your reasoning is valid. However, most of us are trying to help run a business and don't have the luxury of telling our boss that it's academically correct.