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.
--Kris On May 26, 2013 5:46 PM, "Sanford Whiteman" < swhitemanlistens-softw...@cypressintegrated.com> 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 function). > > Was there something that indicated I don't know how to do this? I have > always done it and have no problem with it. I don't mind how it works > now at all. > > Lester's point is UTC is the right default (and thus the battle over > the E_WARNING should be settled that way). I happen to agree with that > part, but disagree from heavy experience with the notion that "UTC or > end-user-selectable" is the only choice you have once you set a value. > > > Let the user has an option and use this option to set the right TZ at > > the beginning of each request. That's what every tool I know does. > > (a) You don't know all the tools in the world. > > (b) Please show me how every major web app gives you a clearly visible > and encouraged option to set the tz _at the beginning of each session_ > (I don't think you mean request). Happy to send screenshots to the > contrary. > > (c) When a web app lets the user change her/his profile parameters > (which is certainly common) this is irrelevant to their session (so if > they change it when they're in City A, they have to change it again in > City B and C as they jump around), (b) on an advanced setup tab > somewhere. > > You're dead wrong if you think traveling telecommuters are always > looking at -- let alone want to look at -- their local time. > > > That being said, I do not knwow which apps you use to organize your > > time plans but all we used here do the conversion for you. Users > > hate, me included, to have meetings and other time related > > activities notifications using a different TZ that the one where I > > am (which can change). > > Well... that's not the way every set of organizations work, hate to > break it to ya. For some apps the Chennai office is at least in part > on San Francisco time. This can be because they remote in and don't > constantly set the TZ in their Citrix session, or because they use a > web app and, like most real users, can't be bothered to find the > setting and are not in any way nagged to do so. > > This doesn't mean that some scheduler app doesn't display their local > time _as well_ as the origin time. But have you ever seen the ol' wall > of world clocks? There's a reason for that. I like to work that way > and so to lots of humans. > > > Then do it this way: > > > - default in php.ini > > - override default is an user has his TZ option set > > I don't need these instructions, which are quite condescending. (And > if you think *I* need them, how can this coexist with the fantasy that > non-programmers always tightly manage their TZ?) > > -- S. > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
