Warning: date(): It is not safe to rely on the system’s timezone settings
If the server’s time zone is what you want, then you are fine, however, PHP wants you to explicitly “say so” or you will get warnings: … or all functions that use the system time, in any way, will run 2 to 5 times slower! I experienced that using this function highly increases performance of functions like getdate() or date() using PHP 5.2.6 on Windows.
– http://answers.google.com/answers/threadview/id/739376.html In most cases, worrying about this is overkill (in my opinion) but the point of asking for strict error reporting is that you want the nitpicking. If you don’t want this level of nitpicking, you may want to turn off strict error reporting. According to PHP’s documentation for date_default_timezone_get(), this is the order [of resources from] in which the time zone is [acquired]: 1. The timezone set using the date_default_timezone_set() function (if any) [in a program] It is the job of every OpSys to provide the date and time and they all do. No guessing required. – however, is it sad to know that php does not make it memory-resident with the first access, the failure to do so is causing it to run 2 to 5+ times slower! use “@” to suppress the bogus warnings. use It reminds us that there are places where quotes are requested but not necessary, and php gives a warning. “You are *required* to use the date.timezone setting or the date_default_timezone_set() function.”
It IS safe to rely on the system’s timezone settings Just be explicit and say so.
@date_default_timezone_set (date_default_timezone_get());
Warning: date(): It is not safe to rely on the [operating] system's timezone settings.
which, of course, is hogwash. But, if you explicitly tell PHP to use the system time-zone,
in a config file or whatever, your date-time function calls [like date() and strtotime()] will run faster:
set date_default_timezone_set() FOR SPEED
@date_default_timezone_set(date_default_timezone_get());
I experienced similar results on Linux servers with PHP 5.2.6 and 5.2.10, although the difference was not that significant on these servers: The PHP 5.2.10 server did run with date_default_timezone_set (“only”) twice as fast as without. The 5.2.6 server did 5 times faster with date_default_timezone_set. The 5.2.6-Windows machine did a LOT faster. [almost 20 times faster!]
Of course these machines have completely different hardware and can not really be compared, but all show improved performance.
– Christopher Kramer 09-Jan-2010 03:52 http://php.net/manual/en/function.date-default-timezone-set.php
[The reality here is that there is some kind of very heavy overhead system look-up going on that is eliminated by telling php the zone in a function. . . . as if the interpreter could not have done this without having to be told!]
The E_STRICT setting causes PHP to report errors based on what the PHP people decided good coding practice to be. In this case, they seem to believe that you should be explicit about what time zone you intend to be in, rather than depending on the server to provide the information. [though, that IS every servers job, of course, not php’s.]
[error_reporting(E_ALL ^ E_NOTICE) skips the “nitpicking” and still warns you of “deprecated”, soon to be removed, functions.]
2. The TZ environment variable (if non empty)
3. The date.timezone ini option (if set)
4. “magical” guess (if the operating system supports it) – php has been getting it quite reliably since “day one”.
(I experienced that even if I set TZ, php will still complain with warnings)
@date_default_timezone_set( date_default_timezone_get() ); to suppress the false warnings once and for all. (in the top of your first include file)
Html (or java-script?) is the worst at wanting quotes almost everywhere, though they are seldom necessary, and in php, we can end up with quotes within quotes within quotes! It gets absurd, much more, impossible to read, with all the backslashing going on. … not to mention all the problems with a program not running and no error messages because of some mis-matched quote!