Vladkornea,
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.
Part of this has to do with addressing client/server issues, which may
occur when (for example) the server is in Pacific Time and the client
is in Eastern Time. Or there are two servers. One is in Eastern time
and one is in India, but company headquarters is in California and
wants all transactions stamped with their local time regardless of
origin. Which time zone do you want in those cases? Good coding
practice says "Be explicit and specify which time zone you intend."
There is also a bug in GNU that may affect time zone settings, and
using date_default_timezone_set() would also protect from that. This
bug is detailed on the man page for date_default_timezone_set() - to
which a link is provided below.
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.
The manual page for date_default_timezone_set() explaing the effect of
strict error reporting on these functions.
PHP Manual - date_default_timezone_set()
http://us2.php.net/manual/en/function.date-default-timezone-set.php
- Hammer
Search strategy
----------------
Searched the PHP Manual for date() and date_default_timezone_set().
Additional Information
----------------------
PHP Manual
http://us2.php.net/manual/en/index.php |
Request for Answer Clarification by
vladkornea-ga
on
19 Jun 2006 12:45 PDT
<i>One is in Eastern time and one is in India, but company
headquarters is in California and wants all transactions stamped with
their local time regardless of origin. Which time zone do you want in
those cases? Good coding practice says "Be explicit and specify which
time zone you intend."</i>
According to the documentation for date_default_timezone_get(), this
is the order in which the time zone is "guessed":
1. The timezone set using the date_default_timezone_set() function (if any)
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)
As the warning message I initially listed shows, PHP is forced to use
method 4 to "magically" guess the time zone because none of the first
3 methods are available to it, and this is "unsafe." You seem to
saying that all date_default_timezone_set() does is take the
information it obtained from that guess (4) and calculates a new time
zone from it which then applies for the duration of the script's
execution. For example, it makes a "magical guess" that the server
time zone is 'America/New_York', and then if I do:
date_default_timezone_set('America/Los_Angeles');
it will subtract 3 hours from the system time for the purpose of PHP's
date & time functions.
Is this correct?
|
Clarification of Answer by
hammer-ga
on
19 Jun 2006 16:56 PDT
Vladkornea,
I can't be certain of the exact mechanism used by
date_default_timezone_set() without reading the PHP source code. I
expect that it does something along the lines of using the time zone
info reported by the operating system to convert the system time to
GMC, which it would then convert to your requested time zone. This is
close to what you describe, but I expect that, rather than trying to
figure out the differential between the system time zone and yours, it
goes to and from a standard time like GMC.
- Hammer
|
Clarification of Answer by
hammer-ga
on
19 Jun 2006 17:17 PDT
GMC should be GMT. Sorry, can't type tonight. Twice.
- Hammer
|
,
0 Comments
)