Symmetri Developer Blog

———————

PHP timezones example
written by Simon Hutchison - http://www.econfirm.com.au/

———————
date_default_timezone_set("Australia/Sydney")
Sun, 02 Mar 2008 14:57:11 +1100
date_default_timezone_set("Australia/Perth")
Sun, 02 Mar 2008 12:57:11 +0900

———————
The comments in this example assumes server is Sydney time.
———————

Demonstrating that timezone is not important for mktime(), date(”U”) and time(). Get GMT 0. Uses the server time to adjust to GMT 0 so need to ensure server time is correct for these functions to be accurate.

date_default_timezone_set("Australia/Perth")
mktime() : 1204430231
date("u") : 1204430231
time() : 1204430231

date_default_timezone_set("Australia/Sydney")
mktime() : 1204430231
date("u") : 1204430231
time() : 1204430231
———————

Now that we know this we can use these functions to compare to other GMT 0 adjusted times.

Demonstrating that timezone is critical for date(”date format string”) and strtotime(”date string”) because it takes a user string from anywhere in the world!!

date_default_timezone_set("Australia/Sydney")

The next values of time() and strtotime will be very close (within a second) because both the default timezone and the server time is Sydney.

strtotime(): 1204426991
time() : 1204430231 just after the strtotime converted date/time
date("r") : Sun, 02 Mar 2008 14:57:11 +1100x
date_default_timezone_set("Australia/Perth")

The next values of time() and strtotime will be about two hours apart because the default timezone is Perth and the server time is Sydney.

strtotime(): 1204434191
time() : 1204430231 about two hours before the strtotime converted date/time for Perth time. (Remember the server is in Sydney)
date("r") : Sun, 02 Mar 2008 12:57:11 +0900

This means that mktime() can be used to compare any normalised (strtotime with timezone set) time Normalise all incoming user dates using strtotime with date_default_timezone_set set correctly.

———————

These functions may help supporting timezones in PHP

/**
 * This function returns the server timezone offset in seconds
 * e.g. Sydney in DST returns +1100 / 100 * 60 * 60 = 39600
 */
function getServerTimeZoneOffset()
{
    return date("O") / 100 * 60 * 60; // Seconds from GMT
}
/**
 * This function returns the local timezone offset in seconds
 *   where getTimeZone($userid) returns a timezone see below.
 */
function getLocalTimeZoneOffset($userid)
{
    return getTimeZone($userid) / 100 * 60 * 60; // Seconds from user GMT
}
// Now converting a server timestamp to a local timestamp is very simple.
/**
 * Will take a timestamp and minus off Server GMT and add on user GMT seconds
 * thereby making a local timestamp from a server timestamp.
 */
function getLocalTimestampFromServerTimestamp($userid, $timestamp)
{
    return $timestamp - getServerTimeZoneOffset() + getLocalTimeZoneOffset( $userid );
}
//And getting the local time from a user entered date is a useful function.
//Combine the next two functions to achieve just that.
function getLocalTimestampFromDateTime($userid, $datetime)
{
    $timestamp = strtotime($datetime);
    return getLocalTimestampFromServerTimestamp($userid, $timestamp);
}
/**
 * If you have a localized timestamp and just want to get the date format use this.
 */
function getFormattedDate($userid, $timestamp)
{
    return date("Y-m-d H:i:s " . getTimeZone($userid), $timestamp);
}
/**
 * Returns a timezone in the format +0000
 *  e.g. Perth in DST returns +0900
 */
function getTimeZone($userid)
{
    return "+0900"; // Perth in DST
}

If you are looking for an implementation of XML-RPC in PHP, I can recommend Keith Deven’s XML-RPC Library for PHP (v 2.5) as an excellent solution. Although the XML-RPC for PHP open source project is more comprehensive and more widely used (I think), the disadvantage that I saw was that it was far too complex to actually use, especially when building the server. Keith Devens’ solution, by contrast, is far cleaner, simpler and easier to understand. And the more software I write, the more I appreciate simplicity as a virtue.

I am writing a Web Service that returns data in simple XML 1.0. The character encoding of the data is UTF-8, but writing the XML output, I found that responses were sometimes throwing errors on the XML parser on the client side, with an "Invalid character in XML …" type error (for example, using the XML parser built into Firefox).

It turns out that my data contains a number of control characters that lie outside the range of valid XML 1.0 characters (see http://www.w3.org/TR/REC-xml/#charsets):

Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]