Le février 27, 2010 05:34:08 PM, Raphael Geissert a écrit : > On 27 February 2010 14:53, Filipus Klutiero <[email protected]> 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 change timezone. > "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 basically works. Thank you -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
