I would strongly suggest avoiding messing with UNIX timestamps to make it look like a different time zone. This is a lesson I've learnt the hard way, way too many times.
A timestamp is the number of seconds since Midnight 1 January 1970, GMT. It doesn't matter where you are in the world, a given timestamp represents the exact same moment in time, regardless of time zones. Yes, the timestamp "0" means 10am 1/1/70 in Australia, Midnight 1/1/70 in London and 5pm 31/12/69 in LA, but this doesn't mean you can simply add or subtract values and guarantee accuracy.
The golden example which stuffed me up every year for way too long was when daylight savings would crop up. Daylight savings means that there are "clock times" which don't exist in certain parts of the world. For example, in most parts of the US, there was no such time as 2:01am on April 2, 2006.
Enough quasi-intelligible ranting though. My advice is to store your dates in the database as timestamps, and then...
For example,
$timestamp = time();
echo "BRISBANE: " . date('r', $timestamp) . "
";
echo " UTC: " . gmdate('r', $timestamp) . "
";
date_default_timezone_set('Africa/Johannesburg');
echo " JOBURG: " . date('r', $timestamp) . "
";
// BRISBANE: Tue, 12 May 2009 18:28:20 +1000
// UTC: Tue, 12 May 2009 08:28:20 +0000
// JOBURG: Tue, 12 May 2009 10:28:20 +0200
This will keep your values clean (you don't have to be worrying about adding offsets, and then subtracting before saving), it will respect all Daylight Savings rules, and you also don't have to even look up the timezone of the place you want.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…