Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

Again, why can't we just bypass this whole argument by adding a configure option? Something like --date.default_timezone="America/Los_Angeles"? It could then build that in so it'll assume that if there's no php.ini or if it's just not set in there. Problem solved, everybody's use-case covered.

Re: [PHP-DEV] Proposal for better UTF-8 handling

hi! On Fri, May 24, 2013 at 3:17 AM, Rouven Weßling wrote: > Hi Internals! > > First let me introduce myself, my name is Rouven Weßling, I'm a student at > RWTH Aachen University and I'm one of the maintainers of the Joomla! > Framework (née Platform). I've been following the internals list for

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

hi, On Mon, May 27, 2013 at 2:45 AM, Sanford Whiteman wrote: >> Then set the TZ to UTC or whatever else fits your needs. Server side >> TZ from a php point of view can be set to whatever you want, be at the >> php.ini level or in your application configuration (and call the >> appropriate functio

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

On 2013-05-27 07:10, Sanford Whiteman wrote: In general, I use the principle of "domain time." If a site serves a (stock) exchange that closes at 4:00pm Eastern time, people hitting that site from all over the world are not going to necessarily remember that close-of-business is such-and-such UTC

Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context

On Tue, Mar 26, 2013 at 6:45 PM, Ferenc Kovacs wrote: > > > > On Sun, Jan 20, 2013 at 8:17 PM, Gustavo Lopes wrote: > >> I've opened the vote for the "remove calls from incompatible context" RFC: >> >> https://wiki.php.net/rfc/**incompat_ctx#vote >> >>

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

> TZ setting is meant to be the timezone that your site is serving. Of > course, if the site is meant to serve multiple zones, then UTC may be > appropriate. But if your site is a local shop in Elbonia, then all your > times would be appropriate to Elbonian timezone, because all activities > are do

Re: [PHP-DEV] Proposal for better UTF-8 handling

Hi! > I agree with Nikita — I'm not against adding more Unicode/charset > handling functions if they make sense (and I haven't looked at the > code for this particular proposal yet), particularly if they'd be part > of a default build, but enough water has hopefully passed under the Did you mean

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

Hi! > Which is really not that nice. Why is running without an ini file even > an option if it's punished by default behavior? So you want -n to be removed? Probably is not going to happen. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

Hi! > As more and more site/services are being hosted in the cloud, allowing > requests to be handled locally geographically, in different timezones, > does it make ANY sense in setting a timezone at all other than UTC? There's no relation between location of the server/site and the timezone. If

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

Again, why can't we just bypass this whole argument by adding a configure option? Something like --date.default_timezone="America/Los_Angeles"? It could then build that in so it'll assume that if there's no php.ini or if it's just not set in there. Problem solved, everybody's use-case covered.

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

> Then set the TZ to UTC or whatever else fits your needs. Server side > TZ from a php point of view can be set to whatever you want, be at the > php.ini level or in your application configuration (and call the > appropriate function). Was there something that indicated I don't know how to do this

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

hi! On Sun, May 26, 2013 at 9:43 PM, Sanford Whiteman wrote: >> Until a user logs into a site and provides the data of their current >> daylight saving 'location' > Which we might as well assume will never happen. I know our users > don't waste time on this step if it's optional, and I'm not goi

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

> Until a user logs into a site and provides the data of their current > daylight saving 'location' Which we might as well assume will never happen. I know our users don't waste time on this step if it's optional, and I'm not going to push an E_FATAL onto them by saying I'm not going to show them

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

>> I did not do a very good job explaining what I meant. I meant to say >> that requiring the timezone to be set prevents you from running >> without an ini file without any warnings. This is a big annoyance. > > If you insist on using the tool in a wrong way, you will be annoyed as > the tool woul

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

On 26/05/13 13:50, Lester Caine wrote: > Richard Quadling wrote: >> As more and more site/services are being hosted in the cloud, allowing >> requests to be handled locally geographically, in different >> timezones, does >> it make ANY sense in setting a timezone at all other than UTC? > > This is

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

Richard Quadling wrote: As more and more site/services are being hosted in the cloud, allowing requests to be handled locally geographically, in different timezones, does it make ANY sense in setting a timezone at all other than UTC? This is something I have been saying all along. The whole thi

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

On 26 May 2013 07:44, Stas Malyshev wrote: > Hi! > > > I did not do a very good job explaining what I meant. I meant to say > > that requiring the timezone to be set prevents you from running > > without an ini file without any warnings. This is a big annoyance. > > If you insist on using the too

Re: [PHP-DEV] Cannot call constructor

> It can be perfectly ok to allow the lib to be extended and the constructor > extended/replaced with a compatible one. Well sure, it's great to override constructors completely. If the lib authors didn't want you to do that, they should've made it final (which is what I said they should do now).