[php-maint] Bug#571762: Bug#571762: [php5] please get rid of "Warning: date() [function.date]: It is not safe to rely on the system's timezone settings."
chealer at gmail.com
Sat Feb 27 22:59:29 UTC 2010
Le février 27, 2010 05:34:08 PM, Raphael Geissert a écrit :
> On 27 February 2010 14:53, Filipus Klutiero <chealer at gmail.com> wrote:
> > With PHP 5.3, it is now strongly recommended to set the timezone; failure
> > to do so makes date('U'), for example, trigger an E_WARNING (while time()
> > is fine):
> > http://www.php.net/manual/en/function.date-default-timezone-set.php
> > This is really annoying.
> If you want to change that, file a bug report upstream.
> > For example:
> > I have *no idea* where 'EST/-5.0/no DST' comes from, although the system
> > *is* in GMT-5. IMO, there's even a bug here. The default PHP
> > configuration doesn't set date.timezone. This is, IMO, the right thing to
> > do. Searching for elements of this message on Google gives an idea of how
> > much this change broke.
> Why do you think that hard-coding (even if modified at install-time)
> the time-zone is better than letting php figure it out at runtime?
I was saying I think it's better to get the timezone at runtime, as is
currently done. Configuring it would leave it outdated if the system would
> "EST/-5.0/no DST" comes from a call to the localtime_r(3) function,
> refer to its manpage for more information.
> > Telling me that my Debian system's timezone settings are unreliable is
> > not something I expect from software coming from timezones less than 10
> > years behind mine. A *change* in this direction is quite frustrating.
> > Since date_default_timezone_set() was not used, TZ is not set and
> > date.timezone was not set, date_default_timezone_get() must be "Querying
> > the host operating system (if supported and allowed by the OS)".
> And that's exactly what it does.
That must be right, and PHP must be using localtime_r incorrectly, although it
More information about the pkg-php-maint