mkdate function and timezone conversion problems

[Anon]

Hi

Here's the problem: have a solaris server running apache + php3, located in Canada.

Hosting a website that is for an Australian audience, and having all sorts of problems doing time conversion.

I've tried to use the mkdate function to give me a time that is 810 minutes ahead of the server's local clock, but to no avail.

I don't have the code with me but it looks something like this (made human readable):

echo date("format for date", mktime(local hours, local minutes+810, local seconds, local month, local day, local year));

The php manual says that "Mktime() is useful for doing date arithmetic and validation, as it will automatically calculate the correct value for out-of-range input."

But it seems that it can't reliably do it with such large values in the minutes field... sigh... anybody any ideas how to get around this or do it better?

Thanks

[Anon]

I've tried this script that I found at www.php.net and it doesn't work... The TZ/PHP_TZ environment variables change, but the time doesn't...

<?

putenv("PHP_TZ=Canada/Eastern");
$timestamp=mktime(date("H"),date("i"),date("s"),date("m"),date("d"),date("Y"));

// Show the time
echo "Date ".date("d/m/Y H:i:s",$timestamp)." in ".getenv ("PHP_TZ")."\n";
echo "Date ".date("d/m/Y H:i:s")." in ".getenv ("PHP_TZ")."\n";

// Now Change the Timezone

putenv("PHP_TZ=Australia/Adelaide");

echo "Date ".date("d/m/Y H:i:s",$timestamp)." in ".getenv ("PHP_TZ")."\n";
echo "Date ".date("d/m/Y H:i:s")." in ".getenv ("PHP_TZ")."\n";

putenv("TZ=Australia/Adelaide");

echo "Date ".date("d/m/Y H:i:s",$timestamp)." in ".getenv ("TZ")."\n";
echo "Date ".date("d/m/Y H:i:s")." in ".getenv ("TZ")."\n";

?>

[Anon]

I've found that the correct time is produced reliably with the following line:

echo date("D, j F Y, g:i A", mktime(date("H"),date("i"),date("s"),date("m"),date("d"),date("Y"))+48600);

ie. by moving the offset outside of the mktime function and just adding 48600 seconds (ie. 13.5 hours).

I would rather use the OS's inbuilt timezone handling, because that will correctly handle daylight savings time and the like. Ah well.