Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
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 tool in a wrong way, you will be annoyed as the tool would not work in a way you want it to work. The right way is to set up the ini file. It takes about 2 seconds. -- 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
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). You have every reason to expect this will work and keep working. Without call super. But extending a constructor in some made-up way where you override and just *guess* you need to call super if one exists -- after your additional code? before? why one over the other? -- without any formal documentation at all about the consequences? I think that's a stink bomb and I'm sticking with that view. It's like you're treating the superctor as simultaneously opaque and knowable. Say it happens to work at first b/c you don't touch any resources that the superctor needs, or you assign them and the superctor runs afterward and resets them to a workable state (unbeknownst to you). For the sake of argument, let's call this compatibility instead of luck. And how do you keep it compatible? You don't. They could change the superctor signature (oops! you're out of luck because you don't pass them what they need). Internally, they could change what resources superctor expects you to leave alone, what it doesn't, and in what order. It's simple to break this kind of thing, where a third-party doesn't want you to do something but they forgot to stop you. Either the lib author needs to add an empty constructor into every class just to make sure that it will be there to provide a painless upgrade when the need arises for a constructor There's no guarantee at all that it will be painless, because the signatures could mismatch, not to mention every single other dependency being subject to your guesswork. If the authors change their approach, it should be to the Template Method/subinit pattern, not making an official Call Super reqt that'll still be doomed to failure. otherwise the lib consumer has to write boilerplate to make sure that the parent constructor will be only called whet ot is there. Which is still just a guess, and basically doomed. Why would you think you can run an opaque parent:__construct() at any time? I would never just trust that. And I'm hardly risk-averse. :) Look, my gripe isn't with silencing/catching the call to unknown methods in lieu of method_exists(). If that gets easier to do in the language, fine. But I think this use case stinks as a justification. Still, I'll lay off after this e-mail because I will have said my piece. :P Your example also shows an overengineered solution for a simple problem. But it's 4 lines long! The rest is comments and examples of usage. And it's a _real_ solution to the problem, so it could only be overengineered vs. something else that is functionally equivalent. The Template Method pattern ensures that the child classes do not need to remember to invoke a particular method within their initializer. Simply by having an init() method in your derived class, you ensure that upper-level dependencies will be taken care of, and you don't have to have an init() method at all if you don't want to, or you can have an empty one with no side effects. The initialization hierarchy is baked into the object model at the outermost possible layer (since you can't go one more level out into language constructs). This doesn't mean you don't need documentation of what you should/shouldn't do when you init, but it is way closer to being manageable over time. The Call Super pattern requires that the user remember to call within their ctor code, and even worse, the situation under discussion is truly the worst possible argument for the pattern, since _you don't even have any word from the library author_ that call super is recommended or required... so not only can you not enforce the contract, you're making up the notion of the contract off the top of your head. Cheers regardless -- -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
On 26 May 2013 07:44, Stas Malyshev smalys...@sugarcrm.com 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 tool in a wrong way, you will be annoyed as the tool would not work in a way you want it to work. The right way is to set up the ini file. It takes about 2 seconds. Not in direct response to the above point, but more of a comment on this thread, and the various reappearances of this thread. As I understand things, some of the issues with asking the OS for the timezone are: 1 - The OS may not present a timezone in a way that PHP can easily access in a consistent way (i.e. too many flavours, mechanisms, etc.). 2 - The machine's local time and/or timezone may not be set correctly anyway. A point come to mind, in addition to all of this (and I'm not an expert, but this may be important) ... 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? From what I can see, a server (which may not be under our control) COULD have pretty much any time and/or timezone on it. So even if we DO set a timezone in PHP, the time could still be out and that really isn't a good thing. If setting the timezone is so critical that a warning MUST be given when it is not set and that by ignoring the warning (either because of a lazy dev or a dev who cannot see the warning due to shared setup or something else) the scripts running that rely on accurate datetimezone, why not make this a fatal error. Yes. I know you've all jumped off your chairs to complain, but either PHP MUST have this setting appropriately, or it can live without it. The grey area of PHP can run, but your results, well, meh! does not fit well. If all it takes is 2s to set the INI file, why bother running without the setting. Is there any process that could be run that would do the following ... 1 - Determine the machines current date/time. 2 - Determine the machines current timezone (or lack of ability to return that information). 3 - Verify the local time with a known/accurate/maintained time server. 4 - From all of this, make an accurate decision or best guess as to what the timezone should be. 5 - Set an entry in the php.ini file appropriate for the guessed_timezone. So, the warning COULD be given, but allow a dev to run a PHP Team sourced process to determine where in the world the server is (I have access to servers all over Europe. I don't know the timezones that they are all in initially and had to work to confirm that the machine date/time/timezone was accurate. It would seem that a script could do this better, consistently, etc.). Just an idea on trying to solve this. If it could be automated, essentially whatever manual steps a dev would take to accurately set the timezone on an unknown server, then this process would certainly seem to be useful. But only because PHP gives a warning that the lack of the timezone is an issue. Regards, Richard. -- Richard Quadling Twitter : @RQuadling EE : http://e-e.com/M_248814.html Zend : http://bit.ly/9O8vFY
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 thing is broken anyway since you have no idea what time-zone a USER is accessing from since the browser bodge only provides a current time offset. Until a user logs into a site and provides the data of their current daylight saving 'location' anything else is a guess. If you are assuming a server is in a single time-zone, then it makes even less sense to use anything other than UTC and ignore timezones altogether? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 something I have been saying all along. The whole thing is broken anyway since you have no idea what time-zone a USER is accessing from since the browser bodge only provides a current time offset. Until a user logs into a site and provides the data of their current daylight saving 'location' anything else is a guess. If you are assuming a server is in a single time-zone, then it makes even less sense to use anything other than UTC and ignore timezones altogether? If you're writing a CLI script which produces timestamped log lines on stdout, it probably makes sense to use the TZ environment variable, and to fall back to /usr/share/zoneinfo if it is unset, like localtime(). If you're writing a web app which writes timestamped log lines to a local file, it probably makes sense to use whatever timezone is specified in /usr/share/zoneinfo, for consistency with syslogd etc. For timestamps sent to web app end users, you probably want it to be user configurable with UTC as the default, or use some local time for websites with geographically limited interest. It's likely that the timezone of maximum user interest will be different from the server timezone, so it doesn't really make sense to couple the two. In none of these cases does it make sense to require the sysadmin to set a timezone in php.ini before even being able to use the app, so I don't understand why that is the policy chosen by PHP. But like I said in my original post, I really don't mind: thank you for writing ext/datetime, please continue annoying users to whatever extent you see fit. -- Tim Starling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 would not work in a way you want it to work. The right way is to set up the ini file. It takes about 2 seconds. Stas, I'm actually using options provided by the tool: php -n Clearly at some point previously the authors of the CLI API realized that running without an ini file had advantages. For instance, I don't want xdebug and other extra extensions loaded if I'm trying to test performance. The only thing that prevents you from easily doing this is the date.timezone warning. You have to specify it with -d: php -n -d date.timezone=UTC Which is really not that nice. Why is running without an ini file even an option if it's punished by default behavior? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 swhitemanlistens-softw...@cypressintegrated.com 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 going to push an E_FATAL onto them by saying I'm not going to show them timestamps at all unless they set their TZ. Nor am I going to make them see stuff in UTC, because they'll just say, This site's borked and laugh at us and/or assume we're in the UK and go on with their work, instead of seeking a solution. And as I note below, for us at least, the solution is not to have them set their true timezone. 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). If you are assuming a server is in a single time-zone, then it makes even less sense to use anything other than UTC and ignore timezones altogether? Not always, because of something Tim alludes to: principal geographic interest. We run a multi-tenant architecture, and each tenant has a home office in a US city. The time zone at HQ is typically the time zone on which work schedules/deadlines are based, and their users don't always *want* to see their offset applied as they travel to Chennai or Paris for a couple of days. They'll change their phone/watch/laptop timezone, 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. 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). It is true that some of our tenants share the same PHP.INI, so in this respect the INI value itself is not useable, but the principle still applies. It can be set per vhost, per app, etc. A more sensible default than UTC can usually be found using domain and corporate knowledge. For our userbase, setting to New York time by default (that's our time) still would be less confusing than UTC. US residents have an immediate grasp of the West Coast/East Coast 3-hour shift but wouldn't grok the international offsets. Then do it this way: - default in php.ini - override default is an user has his TZ option set As Tim and Richard said, the most interesting timezone has no intrinsic relationship to the server timezone given cloud computing/colocation. And never had, that's how web apps work :) Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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? 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
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 your site is meant to serve specific timezone, it makes sense to set it to that timezone. From what I can see, a server (which may not be under our control) COULD have pretty much any time and/or timezone on it. So even if we DO set a timezone in PHP, the time could still be out and that really isn't a good thing. If you do not control your server, the whole discussion is moot as you can not do anything about TZ settings. sourced process to determine where in the world the server is (I have access to servers all over Europe. I don't know the timezones that they are all in initially and had to work to confirm that the machine TZ setting is not meant to be the timezone the server is physically in. 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 done with regard to this timezone. -- 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
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 would *not* be part of the default build? Because having yet another way of handling utf-8 (also basing on yet another separate library so with potential for incompatibilities and quirks) doesn't look like a good idea. Having yet another PECL ext is not a big deal, but having yet another way by default certainly would only create confusion. -- 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
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 done with regard to this timezone. That's my view to a T... UTC is not the universal best-fit default, nor is end user-defined the only other fit. Depends. Plenty of sites are best seen as geographically fixed even if they have contributing clients who travel outside the local timezone. 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 or such-and-such Tokyo. At best they will need to see the times side-by-side (like the example of world clocks on the wall). And the fact that our clients' end users see the time at corporate HQ by default is just another manifestation of the domain time principle. Some domains don't pretend to be timeless and spaceless. Note this doesn't mean all client software is ignoring roaming time -- we send iCal invites in UTC of course -- nor that, in our case, users they can't change what the site displays if they insist (though they rarely do). It's a question of the best-fit default. Of course, there are many sites for which the best default *is* user-defined or UTC, whichever is found first. It's just not a universal assumption. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
