I guess my point is that I don't believe default settings should trigger errors. If it's a default setting, it's a default setting. Document it and move on. It's then the user's responsibility to define that value correctly if he/she wants something other than the default.
I don't personally see much difference between triggering E_WARNING for date.timezone and -- for example -- open_basedir. There's no error to tell me that my script can access the entire filesystem without an open_basedir setting and that this could be a potential security risk. There's no E_WARNING to say that the default memory_limit value is 128M and that if I want to use more than that I need to define it in php.ini. Where does it stop? It seems like an eminently unsustainable practice to trigger errors for every possible oops in your .ini file. For me, the date.timezone warning has no positive benefit and provides real annoyance every single day. Is that the case for others? I can't say, that's why I'm complaining on the internals list :) On Thu, May 23, 2013 at 4:10 PM, Stas Malyshev <smalys...@sugarcrm.com> wrote: > Hi! > >> I'm probably not the typical PHP user; I spend 99% of my PHP time >> using the CLI (and not web SAPIs). >> This means that I frequently run PHP without an .ini file. As a > > I'm not sure how this follows - CLI is capable of using ini file just > like the rest of SAPIs. Why not create it? > >> The "U" in UTC *does* stand for "Universal," after all. It's a >> sensible default and as such shouldn't > > I don't think it's a sensible default - people don't actually use UTC > when considering dates. A minority of people can use timezone that > coincides with UTC, but not very many use actual UTC. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
