PHP 5.4 Can't Determine Time Zones on its own

Question

I\'m just looking for a little clarification on this. PHP 5.4 eliminated the TZ environmental variable and the \"guessing\" that date_default_timezone_get used

Answer 1

There is no reliable way to guess timezone on every system. Different systems use different conventions and sometimes even different timezone definitions (such as Unix and Windows), sometimes have conflicting timezone specifiers (the same 3-letter zone abbreviation can mean different things in different places). So if you want to have code that is portable between systems, the only way to reliably do it is to ask the user. See for example this thread: http://marc.info/?t=132356551500002&r=1&w=2 on some of the issues with it (look for emails from Derick Rethans - he is the PHP datetime extension maintainer).

If you have a way to find out timezone that you trust - such as TZ variable - then you could always do date_default_timezone_set($_SERVER['TZ']);. However in general this is not a reliable method, so it must be your decision to trust it, PHP can not make it for you.

Answer 2

This is just a wild guess. Could you be able to get the timezone with:

date('H', 0); or something like that? I mean since the unixtime stamp is the same in all regions but the Hour differs, shouldn't you be able to base on the hour know which timezone is used?

Answer 3

If you look here you can see the code from PHP 5.3 that would attempt to guess the system timezone. There isn't that much to it, but it appears the reasons for removing the guessing is mostly related to DST as that is where the issues seem to surface.

A breakdown of the whole guessing process looks like:

• Checks to see if it's already defined globally (php.ini or previous guess) (line 851-853)
• Check TZ environment variable (rarely ever defined from my experience) (line 855-858)
• Check date.default_timezone from php.ini (special case as it should already be defined) (line 860-872)
• Try to guess the timezone from the system by comparing the time() against the localtime(). The spec seems to say setting the timezone is optional, as there could be issues with threaded versions of this call (line 873-890)
• Win32: Call WinAPI function GetTimeZoneInformation() and try to determine system time zone (line 893-928)
• Netware: Check the _timezone value if defined (line 929-937)
• Fallback to UTC if none of the above checks succeeded

I can only speculate, but maybe they only removed it since it was a guess to begin with and isn't always reliable.

Also due to PHP's popularity, it is installed on almost every Linux based shared hosting plan where the customers are often not in the same timezone as the server so falling back to the server timezone for those people is no better than using UTC by default. Then it only causes confusion as these customers have to come to SO to ask why the time is wrong in PHP.

I'm not familiar enough with C and the standard, but it seems like guessing timezone based on localtime has issues with multithreaded code or isn't available in some cases. Since on non-Windows platforms, this is the best way to determine the timezone, it doesn't make sense to do if say half the time it doesn't return anything or causes problems for multi-threaded PHP.

Then of course there is the issue of DST in some places where the timezone and offset is different based on the time of year.

Hope that helps.

Answer 4

On a Windows server, it is possible to get the local system time zone with a little bit of math:

<?php
  date_default_timezone_set('UTC');

  $nowUTC = new DateTime();
  $nowSys = new DateTime(exec('echo %time%'));
  $offset = $nowUTC->diff($nowSys);

  echo $nowUTC->format('H:i:s') . '<br />';
  echo $nowSys->format('H:i:s') . '<br />';
  echo $offset->format('%H');
?>

From my locale (UTC-05) at the time of writing the output of this code is:

22:16:41
17:16:41
05

There is one caveat: the timestamps can sometimes be off by 1 second, causing the $offset variable to have 4:59:59. Getting the correct timezone consistently should do a little bit of rounding to be safe.

Answer 5

I recently built several servers for a project, from the ground up. Due to previous experience on other projects where servers were using local-timezones I opted to force every server to use the 'UTC' timezone. Although this resulted in log files being off by 7 hours (UTC - PST), it did remove the inconsistency that setting local timezones caused (from the previous project).

The forced consistency proved helpful at the OS and app layers. For the OS layer, all log file entries can be viewed from a centralized location (via syslog over udp) regardless of their physical location. And at the application layer it was much easier to store every timestamp as UTC, then convert on the render for users who specified a timezone. This one way conversion is much simpler than a two way conversion, where you would have to convert the timestamp to UTC from the server's local-timezone upon save, then convert it to the user's selected timezone upon render.

So unless there is a very compelling reason for your servers to timezone aware, I would opt to stick with UTC, which was the default previous to 5.4: "If none of the above succeed, date_default_timezone_get() will return a default timezone of UTC."

Answer 6

No, there is no way to retrieve the timezone on a PC at this time.