hi, On Mon, May 27, 2013 at 2:45 AM, 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.
That's right. But I really don't want to use an app unable to deal with TZ :) > (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. Exchange, OpenExchange or almost all calendar/planning oriented apps. I do mean request not session. PHP scripts live within a request, some settings can be set at the beginning of each request (how per host/dir setting works). A session is a set of multiple requests. However an app may store some session related data in a session. > (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. Yes, that's what everyone I work with does and has to to do loose their mind with manual conversions. > You're dead wrong if you think traveling telecommuters are always > looking at -- let alone want to look at -- their local time. Different experience. >> 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. It seems that you are confused between client TZ and server TZ. Also it seems that there is also confusion between displaying time and storing time. Nothing prevent an app to store time data using a given TZ and display it using the relevant TZ, > 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?) I can't do anything but tell some advises, I'm sorry if you take them as condescending, they are not. It is only about technical and design questions, we discuss them, exchange ideas or solutions, that's it. That being said, all these points are not really relevant here. This thread is all about avoiding adding one line to a php.ini for the lazy one, or one call to a date function. If an application is hardly linked to a given TZ then a php.ini default is strongly recommended, no default TZ will ever help here. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
