Why is this a problem? Just fix the code, and fix the data.
UPDATE db_table SET db_value = db_value - 18000;
Easy!
Er, not that easy. The offset is different depending on the whether or not we were in DST.
Epoch time is not dependent upon your time zone. It is defined as the number of seconds that have elapsed since 1970-01-01T00:00:00GMT.
You know that, and I know that, but the original developer of my app didn't know that... so even though he was using the MySQL Unixtime date format he was still doing the TZ offset. So he actually shifted the stored values to +4 or +5 GMT.
And that's hard to spot when you're storing time as a long integer. It means nothing to us.
Now, when you store it as an actual DATETIME, you can read that. If you insert a record at 2012-03-13 1:00pm local time (-4 offset) and it shows up as 2012-03-13 9:00pm you know something is wrong with your code. Well, as long as you know what time it should be in GMT/UTC.
Even better, IMHO, is to store the local datetime value AND the current TZ offset. That way anybody pulling the data can convert from local time to GMT/UTC without looking up anything. You stored the offset for them. And replaying stuff in local time for the events is easy because there's no conversion. When you store in GMT/UTC without the offset the programmer has to reconstruct whatever (government) rules were in place for daylight savings at the time in your current timezone which 99.9% of the time is going to be the same as the place it was recorded except that your DST offset has about a 60 or 40-ish% chance of being wrong so you need to know what the offset was back then. And that means filtering the dates through a library that remembers what the old DST rules were.
I'm not even sure what my point was. I just hate DST and timezones in general as programmer and data warehousing guy. As a retailer I think DST is great though!