On the javascript side, I am not seeging any value in creating the string format for the offset that you are creating, as you just end up spending more code in PHP trying to get to a usable format. Consider keeping offset in minute-based javascript format or converting to second-based format.
I would strongly consider using PHP's DateTime
and related classes (in this case specifically, DateTimeZone
) rather than the procedural date_*
functions. Over time I think you will find them much more powerful and flexible in usage. This also moves you away from the concept of resetting you default system timezone, which I don't think you want to overwrite here, but rather us as fallback.
Let's show an example usage:
// assume $_COOKIE['hp_time_offset'] contains a minute based offset like
// output by javascript Date().getTimezoneOffset()
$system_tz = date_default_timezone_get();
if(!empty($_COOKIE('hp_time_offset')) {
$offset_min = (int)$_COOKIE['hp_time_offset'];
$offset_sec = $offset_min * 60;
// is current system in daylight savings?
$is_dst = (int)date('I');
// get timezone name
$tz = timezone_name_from_abbr('', $offset_sec, $is_dst);
try {
$date_timezone = new DateTimeZone($tz);
} catch (Exception $e) {
error_log('Invalid timezone string of "' . $tz . '" passed from cookie.');
$tz = $system_tz;
}
}
if(empty($timezone)) {
// I am not wrapping this in try-catch as if there is a failure here
// I don't know what you want to do to recover (as this should not happen).
// Feel free to catch if needed for your implementation
$date_timezone = new DateTimeZone($tz);
}
return $date_timezone;
// or if you just want to return the timezone string
// return $date_timezone->getName();
This proposed functionality gives you a valid DateTimeZone
object representing either the cookie-derived timezone or, as a fallback, the system timezone. You can use this object to instantiate any DateTime
object you may need on your system with those objects automatically taking on the expected timezone behavior.