Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
On 2 September 2013 12:16, Nikita Popov nikita@gmail.com wrote: On Mon, Sep 2, 2013 at 11:47 AM, Derick Rethans der...@php.net wrote: On Wed, 28 Aug 2013, Nikita Popov wrote: On Thu, May 23, 2013 at 8:40 PM, Daniel Lowrey rdlow...@gmail.com wrote: 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 result, when I use any of the date/time functionality I invariably end up with this awesomeness: Warning: date(): It is not safe to rely on the system's timezone settings blah blah blah. I was thinking about this again and maybe we could reach the following compromise: * Set date.timezone = UTC as the default INI value * In php.ini-production and php.ini-development uncomment the ;date.timezone = line, i.e. change it to date.timezone = No, php.ini-development should have what PHP does by default. That's not the case currently and as far as I know that is so intentionally. ini-development and PHP defaults differ not just in obscure extension settings, but also in core options like error_reporting, short_tags, maximum_execution_time, variables_order, register_argc_argv, display_startup_errors, output_buffering, etc etc etc. If these differences are not intentional, we should fix this. But I'm pretty sure they are. Nikita Also remember that different SAPI's have defaults too. -- Richard Quadling Twitter : @RQuadling
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
On Wed, 28 Aug 2013, Nikita Popov wrote: On Thu, May 23, 2013 at 8:40 PM, Daniel Lowrey rdlow...@gmail.com wrote: 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 result, when I use any of the date/time functionality I invariably end up with this awesomeness: Warning: date(): It is not safe to rely on the system's timezone settings blah blah blah. I was thinking about this again and maybe we could reach the following compromise: * Set date.timezone = UTC as the default INI value * In php.ini-production and php.ini-development uncomment the ;date.timezone = line, i.e. change it to date.timezone = No, php.ini-development should have what PHP does by default. cheers, Derick -- 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 Mon, Sep 2, 2013 at 11:47 AM, Derick Rethans der...@php.net wrote: On Wed, 28 Aug 2013, Nikita Popov wrote: On Thu, May 23, 2013 at 8:40 PM, Daniel Lowrey rdlow...@gmail.com wrote: 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 result, when I use any of the date/time functionality I invariably end up with this awesomeness: Warning: date(): It is not safe to rely on the system's timezone settings blah blah blah. I was thinking about this again and maybe we could reach the following compromise: * Set date.timezone = UTC as the default INI value * In php.ini-production and php.ini-development uncomment the ;date.timezone = line, i.e. change it to date.timezone = No, php.ini-development should have what PHP does by default. That's not the case currently and as far as I know that is so intentionally. ini-development and PHP defaults differ not just in obscure extension settings, but also in core options like error_reporting, short_tags, maximum_execution_time, variables_order, register_argc_argv, display_startup_errors, output_buffering, etc etc etc. If these differences are not intentional, we should fix this. But I'm pretty sure they are. Nikita
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
On Thu, May 23, 2013 at 8:40 PM, Daniel Lowrey rdlow...@gmail.com wrote: 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 result, when I use any of the date/time functionality I invariably end up with this awesomeness: Warning: date(): It is not safe to rely on the system's timezone settings blah blah blah. I was thinking about this again and maybe we could reach the following compromise: * Set date.timezone = UTC as the default INI value * In php.ini-production and php.ini-development uncomment the ;date.timezone = line, i.e. change it to date.timezone = This would mean that people running PHP without an ini would get UTC as the default and people running with an ini based on php.ini-production/php.ini-development would get the warning. Short of completely dropping the warning this is the behavior that would make most sense to me. (As people running without an ini obviously don't care about setting the timezone) Thanks, Nikita
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
I agree. 2013/8/28 Nikita Popov nikita@gmail.com On Thu, May 23, 2013 at 8:40 PM, Daniel Lowrey rdlow...@gmail.com wrote: 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 result, when I use any of the date/time functionality I invariably end up with this awesomeness: Warning: date(): It is not safe to rely on the system's timezone settings blah blah blah. I was thinking about this again and maybe we could reach the following compromise: * Set date.timezone = UTC as the default INI value * In php.ini-production and php.ini-development uncomment the ;date.timezone = line, i.e. change it to date.timezone = This would mean that people running PHP without an ini would get UTC as the default and people running with an ini based on php.ini-production/php.ini-development would get the warning. Short of completely dropping the warning this is the behavior that would make most sense to me. (As people running without an ini obviously don't care about setting the timezone) Thanks, Nikita -- *** Marcel Araujo Analista de Sistemas Desenvolvedor PHP/Zend/JavaScript/jQuery/NodeJS Linux User #490101 http://www.twitter.com/marcelarauj0 http://blog.marcelaraujo.me http://br.linkedin.com/in/marcelaraujo *
RE: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
I like the idea of defaulting to UTC. Inevitably, this is how I set up my apps anyway. Bryan -Original Message- From: Marcel Araujo [mailto:ceceld...@gmail.com] Sent: Wednesday, August 28, 2013 7:49 AM To: Nikita Popov Cc: Daniel Lowrey; Derick Rethans; PHP internals Subject: Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale? I agree. 2013/8/28 Nikita Popov nikita@gmail.com On Thu, May 23, 2013 at 8:40 PM, Daniel Lowrey rdlow...@gmail.com wrote: 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 result, when I use any of the date/time functionality I invariably end up with this awesomeness: Warning: date(): It is not safe to rely on the system's timezone settings blah blah blah. I was thinking about this again and maybe we could reach the following compromise: * Set date.timezone = UTC as the default INI value * In php.ini-production and php.ini-development uncomment the ;date.timezone = line, i.e. change it to date.timezone = This would mean that people running PHP without an ini would get UTC as the default and people running with an ini based on php.ini-production/php.ini-development would get the warning. Short of completely dropping the warning this is the behavior that would make most sense to me. (As people running without an ini obviously don't care about setting the timezone) Thanks, Nikita -- *** Marcel Araujo Analista de Sistemas Desenvolvedor PHP/Zend/JavaScript/jQuery/NodeJS Linux User #490101 http://www.twitter.com/marcelarauj0 http://blog.marcelaraujo.me http://br.linkedin.com/in/marcelaraujo * -- 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! * Set date.timezone = UTC as the default INI value * In php.ini-production and php.ini-development uncomment the ;date.timezone = line, i.e. change it to date.timezone = I think this is fine but for the distros that ship with empty php.ini it'd still produce a warning. But I think enabling zero-ini to run without warnings (with whatever defaults there are) is a good idea. Maybe still worth having RFC and a vote on it. -- 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?
On Thu, May 23, 2013 3:10 pm, Stas Malyshev wrote: 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. I don't know about everybody else, but if I need a timezone-aware application, I always use GMT/UTC and have I/O routines for user-interface to convert to local for them. -- 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 Peter, You're describing the current behaviour; unless I'm missing something obvious, the warning is only displayed when you try to do something date-related. Your example script should not be presenting any warnings, regardless of the date.timezone INI setting or lack thereof. you are right (I obviously missed some hidden [inside a library] date/time calls when encountering this error). This makes the following statement from Leszek interesting: Also, the check if timezone not set show warning would have to be shifted from initialization to call of each and every datetime function. It seems, like this is the case then. -- Cheers Jannik
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 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. As you have said - there are some use cases, where non-UTC TZ setting is important. But do you think that people running this software wouldn't know that they have to set a proper time zone in ini file? Or at least in app configuration? In my opinion UTC is a good compromise. From my experience, the problem divides into two categories: a) apps that display time on pages and users might be wondering why the time has some shift - it's not a critical setting; it might be set, but without this no key features are borked; b) app is deeply set in a geographic location, like aforementioned stock exchange - proper setting is critical. In a) setting TZ to UTC is not making the website broken - it's just a glitch. Admin can fix the setting if anyone notices the problem - yes, that might stem a lot of bug reports, but as it was with register_globals. In b) admin should really know better that he has to set this in ini. Also, in my opinion, responsibility for the setting should be moved from system administrator to application developer. If app is time-set, it should have a proper setting for this. It was said before that there aren't many systems that require you to set this setting. It was also bashed that you don't know all the apps. Yeah, maybe I don't know all of them, but I've installed Python, Ruby and Java apps (which I assume comprise most of web app environments - ASP aside, but I suppose in this case it's even easier to get proper TZ from environment), and I was never forced to set _any_ option because otherwise my app would be showing some nasty warnings. But that's only my experience. --Leszek -- 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 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
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. If you build php yourself from source there is always the option to throw (comment out) that one particular E_WARNING line ext/date/php_date.c.(that is something I do for example for mysqlnd which complains about non-existing character set on older sphinxsearch instances). But if the OP is annoyed by typing php -d date.timezone=... myfile.php each time he could just make an alias (or doskey in win environment). rr -- 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 Sun, May 26, 2013 at 11:49 PM, Reinis Rozitis r...@roze.lv wrote: 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. If you build php yourself from source there is always the option to throw (comment out) that one particular E_WARNING line ext/date/php_date.c.(that is something I do for example for mysqlnd which complains about non-existing character set on older sphinxsearch instances). But if the OP is annoyed by typing php -d date.timezone=... myfile.php each time he could just make an alias (or doskey in win environment). rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Well yes, but you could make the same argument for a lot of the configure options that are already in place. Personally, if such a configure option existed, I'd probably use it myself, since date.timezone is generally the only manual modification I have to make to php.ini, anyway. If I could set that in configure, I wouldn't have to bother with php.ini at all when doing installs. If there's no downside to adding that option (at least I haven't seen anybody offer one yet) and it has a reasonable use-case (which it does), then why not? It would certainly make a lot more sense than manually editing the source code, particularly for sysadmins who might not have any programming experience. --Kris
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
In my opinion UTC is a good compromise. I agree that _in the absence of any other setting_ there's nothing wrong with using UTC! Let be clear: UTC is a perfectly fine hands-off default rather than issuing a warning. Non-technical end users will guess you're on London time but whatever. I am simply making the point that UTC is not the default default even when sysops or devs put their hands in. The choice isn't just UTC or what the end user personally sets. Domain time exists, no matter if Pierre has experienced it or not. -- 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 Mon, May 27, 2013 at 9:20 AM, Sanford Whiteman swhitemanlistens-softw...@cypressintegrated.com wrote: I am simply making the point that UTC is not the default default even when sysops or devs put their hands in. The choice isn't just UTC or what the end user personally sets. Domain time exists, no matter if Pierre has experienced it or not. Ok, let me rephrase it in a more understandable way. We had it the way you are wishing it. It caused hundred of side effects, bugs reports, bad behaviors, etc. This is something we don't want to see again. Not because either the system administrators or the application developers are not willing to add one line to php.ini or to their application. For all the reasoning behind this choice, please check the numerous bugs reports and discussions on internals. 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?
On 2013-05-27 08:49, Reinis Rozitis wrote: 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. If you build php yourself from source there is always the option to throw (comment out) that one particular E_WARNING line ext/date/php_date.c.(that is something I do for example for mysqlnd which complains about non-existing character set on older sphinxsearch instances). Doing that kind of modification is a straight way to introducing custom bugs ;) Having a community-approved setting is something different. But if the OP is annoyed by typing php -d date.timezone=... myfile.php each time he could just make an alias (or doskey in win environment). ...and in all #! headers, and in all other places. That could be a temporary bypass, not a complete solution. l. -- 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 Mon, May 27, 2013 at 9:27 AM, Pierre Joye pierre@gmail.com wrote: On Mon, May 27, 2013 at 9:20 AM, Sanford Whiteman swhitemanlistens-softw...@cypressintegrated.com wrote: I am simply making the point that UTC is not the default default even when sysops or devs put their hands in. The choice isn't just UTC or what the end user personally sets. Domain time exists, no matter if Pierre has experienced it or not. Ok, let me rephrase it in a more understandable way. We had it the way you are wishing it. It caused hundred of side effects, bugs reports, bad behaviors, etc. This is something we don't want to see again. Not because either the system administrators or the application developers are not willing to add one line to php.ini or to their application. For all the reasoning behind this choice, please check the numerous bugs reports and discussions on internals. Could you please provide a link to discussions that have already taken place on this topic? I just waded through the results for date.timezone warning on markmail, but couldn't find any particularly relevant discussion (apart from this one). Thanks, Nikita
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
In my opinion UTC is a good compromise. I agree that _in the absence of any other setting_ there's nothing wrong with using UTC! Let be clear: UTC is a perfectly fine hands-off default rather than issuing a warning. Non-technical end users will guess you're on London time but whatever. And if you think 'London time' is UTC then you will get just as many problems half of tbe year. Once one is WORKING using timezones, you need to actually understand that for some timezones, the time will be an hour different for half of the year and simply assuming that the time offset from the browser is correct is as bad as assuming UTC is London time. The many problems being tributed to automatically setting a server timezone were always more due to understanding that the server was getting things like daylight saving wrong. Set the server to UTC and then select a DISPLAY timezone makes managing time a lot easier. Add to that the option to user a client set timezone and one is good to go -- 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?
Hello, Am Montag, 27. Mai 2013 um 09:27 schrieb Pierre Joye: On Mon, May 27, 2013 at 9:20 AM, Sanford Whiteman swhitemanlistens-softw...@cypressintegrated.com (mailto:swhitemanlistens-softw...@cypressintegrated.com) wrote: I am simply making the point that UTC is not the default default even when sysops or devs put their hands in. The choice isn't just UTC or what the end user personally sets. Domain time exists, no matter if Pierre has experienced it or not. Ok, let me rephrase it in a more understandable way. We had it the way you are wishing it. It caused hundred of side effects, bugs reports, bad behaviors, etc. This is something we don't want to see again. Not because either the system administrators or the application developers are not willing to add one line to php.ini or to their application. For all the reasoning behind this choice, please check the numerous bugs reports and discussions on internals. would it be hard to just show the notice as soon as the user actually uses a function regarding to date/time (and not before)? Currently the message is shown all the time, at the start of the script - even if the script is as simple as ?php echo 1; Wouldn't it be more useful if the notice only appears, if I actually use a date/time-function? -- Cheers Jannik 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?
On Mon, May 27, 2013 at 10:35 AM, Jannik Zschiesche he...@apfelbox.netwrote: would it be hard to just show the notice as soon as the user actually uses a function regarding to date/time (and not before)? Currently the message is shown all the time, at the start of the script - even if the script is as simple as ?php echo 1; Wouldn't it be more useful if the notice only appears, if I actually use a date/time-function? That wouldn't solve the problem, because date/time functions are very common, and the warning would still show up for too many people. So we would solve the problem for just a small percent of people, while not solving the key issue. Also, the check if timezone not set show warning would have to be shifted from initialization to call of each and every datetime function. --Leszek
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
And if you think 'London time' is UTC then you will get just as many problems half of tbe year. I said the *end user will assume* UTC timestamps are London time. Not that London time is UTC. People try to fit what they see into something they know. People in US-East see stuff 4-5 hours off, that's what they think. I hear it all the time: I think they're in the UK. A one-hour shift doesn't make them instantly have a come-to-UTC moment. Anyway, that's the unavoidable consequence of defaulting to UTC for storage and display. That's why using domain time as the display default is preferable, when there is a relevant one, further allowing people to set their tz as applicable for their session or user profile (profile == default for future sessions). I do not believe in forcing people to choose this setting before passing authentication in any old web app, as putting up such a barrier can be obtrusive; also, for our apps, it can lead to confusion because the domain time is always known, so we put the option in the user's control panel but don't lead them to it. I'm not talking about storage time zone; we use UTC for that. I'm talking about the default display time zone. Unless we are misunderstanding each other (not unlikely given how this thread has sprawled) you seem to be saying the display time zone should be UTC by default and changed only based on end-user input. I think there are five legitimate levels of consideration (storage tz, sitewide display tz, domain/corporate display tz, stored user profile tz, and transient session 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?
On 2013-05-27 11:00, Sanford Whiteman wrote: I'm not talking about storage time zone; we use UTC for that. I'm talking about the default display time zone. Don't you think that using proper calculations for displaying dates are application developers' responsibility? Whether is it setting a proper TZ in app config, or asking user if it's a better scenario for given app. Unless we are misunderstanding each other (not unlikely given how this thread has sprawled) you seem to be saying the display time zone should be UTC by default and changed only based on end-user input. I think there are five legitimate levels of consideration (storage tz, sitewide display tz, domain/corporate display tz, stored user profile tz, and transient session tz). That's a very valid point. In my opinion, time should be stored and processed in UTF, and only displayed with a proper offset, but, per what I wrote above, I think it's an app's responsibility to display it properly. --Leszek -- 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?
Sanford Whiteman wrote: I'm not talking about storage time zone; we use UTC for that. I'm talking about the default display time zone. Unless we are misunderstanding each other (not unlikely given how this thread has sprawled) you seem to be saying the display time zone should be UTC by default and changed only based on end-user input. I think there are five legitimate levels of consideration (storage tz, sitewide display tz, domain/corporate display tz, stored user profile tz, and transient session tz). Actually I probably am saying 'default to UTC for display' but simply drop the 'UTC' bit altogether! If you want a site to run in a single timezone, then using timezone settings just complicates things. In particular when trying to set a meeting in 6 months time which is the one that caught me out initially. Simply using a raw unadulterated time is the safest way of managing sites that have no real interest in daylight saving. As soon as you NEED to manage timezones/DLS, then the starting point is always to run the server as UTC and manage everything else from that. Running the server on any other setting and trying to store UTC data introduces yet another unnecessary complication. Adding tz as a requirement was the basic mistake here. It has no place on many systems. -- 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 27 May 2013 09:35, Jannik Zschiesche he...@apfelbox.net wrote: Hello, would it be hard to just show the notice as soon as the user actually uses a function regarding to date/time (and not before)? Currently the message is shown all the time, at the start of the script - even if the script is as simple as ?php echo 1; Wouldn't it be more useful if the notice only appears, if I actually use a date/time-function? You're describing the current behaviour; unless I'm missing something obvious, the warning is only displayed when you try to do something date-related. Your example script should not be presenting any warnings, regardless of the date.timezone INI setting or lack thereof. -- Cheers Jannik
[PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
I understand that you can use php -d, but this is not a portable solution. My specific use case is running a libevent-based HTTP server and I cannot even run unit test suites without an .ini file because of this warning. Why does PHP force me to include configuration directives that it clearly doesn't need to function correctly? Forcing users to specify additional command line options on every execution is no less pointless than than requiring an .ini file where none is needed. A user's time zone setting is simply not a language-level concern. Nor is a user's inability to understand how timezones work. I appreciate Derrick's work on the extension but I have yet to see any valid justification for triggering an error when no error actually exists. On Monday, May 27, 2013, Pierre Joye wrote: On Tue, May 28, 2013 at 12:57 AM, Daniel Lowrey rdlow...@gmail.com wrote: My problem with the current behavior is that it essentially *forces* the use of an .ini file by triggering an error if no default is assigned. No it does not. You can use: - php -d ... - date_default_timezone_set Now, as far as I can tell the only argument put forward to justify triggering the error is (summarized): many people are too stupid to set a timezone and don't understand why the results of their date() calls are different from their own timezone. This results in many erroneous bug reports. It is not one of the arguments. The arguments are bad TZ, invalid TZ or inconsistent in system's TZ, which causes hard to catch bugs (and not possible to fix), non portable code (if you rely on a bad TZ), to name only a few. And I stop here for this discussion, I do not see any new arguments on both sides and a default TZ will very unlikely happen. Packagers could deal with that easily and application developers as well. Cheers, -- Pierre @pierrejoye | http://www.libgd.org
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
On Mon, May 27, 2013 at 4:35 PM, Daniel Lowrey rdlow...@gmail.com wrote: I understand that you can use php -d, but this is not a portable solution. My specific use case is running a libevent-based HTTP server and I cannot even run unit test suites without an .ini file because of this warning. Why does PHP force me to include configuration directives that it clearly doesn't need to function correctly? Forcing users to specify additional command line options on every execution is no less pointless than than requiring an .ini file where none is needed. A user's time zone setting is simply not a language-level concern. Nor is a user's inability to understand how timezones work. I appreciate Derrick's work on the extension but I have yet to see any valid justification for triggering an error when no error actually exists. On Monday, May 27, 2013, Pierre Joye wrote: On Tue, May 28, 2013 at 12:57 AM, Daniel Lowrey rdlow...@gmail.com wrote: My problem with the current behavior is that it essentially *forces* the use of an .ini file by triggering an error if no default is assigned. No it does not. You can use: - php -d ... - date_default_timezone_set Now, as far as I can tell the only argument put forward to justify triggering the error is (summarized): many people are too stupid to set a timezone and don't understand why the results of their date() calls are different from their own timezone. This results in many erroneous bug reports. It is not one of the arguments. The arguments are bad TZ, invalid TZ or inconsistent in system's TZ, which causes hard to catch bugs (and not possible to fix), non portable code (if you rely on a bad TZ), to name only a few. And I stop here for this discussion, I do not see any new arguments on both sides and a default TZ will very unlikely happen. Packagers could deal with that easily and application developers as well. Cheers, -- Pierre @pierrejoye | http://www.libgd.org At the risk of sounding like a broken record, adding a configure option would render this entire debate moot. PHP's behavior without the option specified would be identical to the way it is now. With the option specified, PHP would assume a default timezone if one is not set in php.ini, including if php.ini doesn't exist at all. So, bug tracker wouldn't get filled-up with default timezone behavior confusion like before and people like Daniel would be able to easily do their thing without php.ini and without having to change any of their runtime parameters or muck around with the source code. It's win-win. I'd be happy to draft an RFC for this. I really don't see the point in dragging on this heated argument when we can so easily skip around it altogether. --Kris
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] 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] 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
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
On 23/05/13 20:40, Daniel Lowrey wrote: If it's going to default to UTC anyway should there really be an E_WARNING? Can't PHP just quietly use UTC? The U in UTC *does* stand for Universal, after all. It's a sensible default and as such shouldn't merit a warning. Actually, the sensible default is what guess_timezone() does already, except without the warnings. You can get that behaviour with e.g. date_default_timezone_set( @date_default_timezone_get() ); at the top of your program. That's what MediaWiki does (except with by modifying error_reporting instead of using @). We stole the idea from another web app. It's more convenient than duplicating the functionality of guess_timezone() in the application. It's Derick's prerogative to annoy all users half to death with warnings, as his way of indicating his distaste for the state of OS support for querying of system timezone. That's the reward we give him for writing lots of date/time code. -- 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?
On May 25, 2013 12:31 PM, Tim Starling tstarl...@wikimedia.org wrote: . It's Derick's prerogative to annoy all users half to death with warnings, as his way of indicating his distaste for the state of OS support for querying of system timezone. It is actually only about getting safe, cross platform/OS (even between Linux versions) for the TZ database. It has nothing to do with taste or similar subjective opinion. For the record, the behavior requested in this thread is what we had in earlier versions, all we got was plenty of bugs reports about wrong TZ detections. I think it is not too much asking to set it in php.ini or in your application.
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
Am 25.05.2013 14:09, schrieb Pierre Joye: On May 25, 2013 12:31 PM, Tim Starling tstarl...@wikimedia.org wrote: . It's Derick's prerogative to annoy all users half to death with warnings, as his way of indicating his distaste for the state of OS support for querying of system timezone. It is actually only about getting safe, cross platform/OS (even between Linux versions) for the TZ database. It has nothing to do with taste or similar subjective opinion. For the record, the behavior requested in this thread is what we had in earlier versions, all we got was plenty of bugs reports about wrong TZ detections. I think it is not too much asking to set it in php.ini or in your application. Wouldn't it be possible to have it default to the system's timezone if available? Most software seems to be able to use the correct timezone. From a user's pov it is strange that PHP is pretty much the only service which has to have it's own timezone configuration. Or maybe one could make it a compile time option and distros that for some reason have no usable system time zone can disable this feature. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com -- 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?
For the record, the behavior requested in this thread is what we had in earlier versions, all we got was plenty of bugs reports about wrong TZ detections. This issue is less about date.timezone than being able to run without an ini file. -- 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 List, Wouldn't it be possible to have it default to the system's timezone if available? Most software seems to be able to use the correct timezone. From a user's pov it is strange that PHP is pretty much the only service which has to have it's own timezone configuration. I appreciate the current state of things. There's only one thing worse than having an operation return the wrong answer, and that's having it return the wrong answer silently. The latter can happen with the wrong TZ setting. I've got a myriad of different systems to deal with, some distro-based installs of PHP separating out php.ini for the CLI, and for Apache. Other installs using the same file like I expect. I make mistakes. I'm currently maintaining ~100 servers from a slew of different providers around the world. The clock is hard enough to trust, let alone what the system's TZ setting is. The #1 answer from providers when we complain that the clock is 2 hours off is to just change the timezone. When I get the blast of warnings, I'm shaken from complacency to invest one minute to find the right file, add the setting, and forget about it once more. paul
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
On Sat, May 25, 2013 at 9:03 AM, Levi Morrison morrison.l...@gmail.com wrote: For the record, the behavior requested in this thread is what we had in earlier versions, all we got was plenty of bugs reports about wrong TZ detections. This issue is less about date.timezone than being able to run without an ini file. 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. -- 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?
It is actually only about getting safe, cross platform/OS (even
between Linux versions) for the TZ database. It has nothing to do
with taste or similar subjective opinion.
For the record, the behavior requested in this thread is what we had
in earlier versions, all we got was plenty of bugs reports about
wrong TZ detections.
I had missed the removal of the TZ detection code from
guess_timezone() in 5.4. So @date_default_timezone_get() is somewhat
less useful than it used to be, as a function for detecting system
settings.
I think it is not too much asking to set it in php.ini or in your
application.
At least for MediaWiki, it's certainly more important to avoid
warnings than it is to have the right local timezone. UTC is used in
any case where consistency is important. Based on other posts to this
list, I don't think we're alone in this.
For the record, the PHP 5.4+ date_default_timezone_get is equivalent to
ini_get('date.timezone') ?: 'UTC'
except that date_default_timezone_get will raise a warning and the
above will not.
--
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 Sat, May 25, 2013 at 5:09 PM, Levi Morrison morrison.l...@gmail.comwrote:
It is actually only about getting safe, cross platform/OS (even
between Linux versions) for the TZ database. It has nothing to do
with taste or similar subjective opinion.
For the record, the behavior requested in this thread is what we had
in earlier versions, all we got was plenty of bugs reports about
wrong TZ detections.
I had missed the removal of the TZ detection code from
guess_timezone() in 5.4. So @date_default_timezone_get() is somewhat
less useful than it used to be, as a function for detecting system
settings.
I think it is not too much asking to set it in php.ini or in your
application.
At least for MediaWiki, it's certainly more important to avoid
warnings than it is to have the right local timezone. UTC is used in
any case where consistency is important. Based on other posts to this
list, I don't think we're alone in this.
For the record, the PHP 5.4+ date_default_timezone_get is equivalent to
ini_get('date.timezone') ?: 'UTC'
except that date_default_timezone_get will raise a warning and the
above will not.
and the fact that date_default_timezone_get wouldn't return invalid
timezone, while ini_get would:
./sapi/cli/php -n -d date.timezone=Foo/Bar -r
'var_dump(@date_default_timezone_get());var_dump(ini_get(date.timezone)?:UTC);'
string(3) UTC
string(7) Foo/Bar
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
This issue is less about date.timezone than being able to run without an ini file. This is my complaint. My point of view is that PHP is a programming language, not some goofball windows application. Forcing me to use an .ini file to be able to program is a real annoyance. And in my humble opinion, triggering a warning because the worst programmers can't correctly set a timezone is a dubious justification. Granted, I don't have to answer the bug reports, but how difficult is it to say, No, this is not a bug. Let me google this for you, and close as Will not fix? People who think a UTC timezone default is a bug are equivalent to my grandparents who think the television is broken because they don't know how to press the remote control's power button. Please, PHP, do we have to accommodate the very lowest common denominator? If you don't kick the baby birds out of the nest they'll never learn to fly. I get that everyone doesn't agree, but this seems like a no-brainer to me. On Fri, May 24, 2013 at 5:35 PM, Nikita Popov nikita@gmail.com wrote: On Fri, May 24, 2013 at 2:40 AM, Derick Rethans der...@php.net wrote: On Thu, 23 May 2013, Daniel Lowrey wrote: 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. No - you, as an admin, are required to make an informed decision on what you want your timezone to be. There have been way too many bug reports where people had no clue, so now we throw a warning. Sorry, but I fail to see why date.timezone needs special handling. What makes the date.timezone setting so important, that it is the only one which value you are required to set? There are settings that are arguably a lot more important than this, but which do not throw such warnings. E.g., why isn't there a warning for cases where error_reporting is not explicitly specified? I can't count the number of StackOverflow questions caused by bad error_reporting settings and I'm very sure this number surpasses complains about timezones by several orders of magnitude. Yet - of course! - we do no such thing, for it is senseless. After all, there *is* a reason why we have defaults for ini settings. People should only be required to changed them when necessary. Date.timezone should be no exception to this. Nikita -- 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 Sat, May 25, 2013 at 6:04 PM, Daniel Lowrey rdlow...@gmail.com wrote: Granted, I don't have to answer the bug reports, but how difficult is it to say, No, this is not a bug. Let me google this for you, and close as Will not fix? Not difficult at all. We already have the quick-fix system in place, exactly for cases like this. It requires one, just one click in the bug mail to close the issue with an appropriate message. This is how other common bogus bugs are handled, for example people reporting wrong float calculations. That's also why I don't buy this bug report argument. I mean, by that line of thinking we should remove the floating point quickfix and instead throw a warning on the first use of floating point numbers that asks whether the user is sure that he understands floating point arithmetic (with the ability to remove the warning with an ini setting). Sure, that's one way to avoid bogus bug requests - but it's a really, really absurd way. And in any case, if you google for things like php time wrong, php dates not correct or php time off by 5 hours the first few results will all tell you to use date_default_timezone_set() etc. Even if you don't know about timezones, this fact should make debugging incorrect times pretty straightforward. For this the warning does not seem necessary. Nikita
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
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. I was wondering - why not get time zone info from operating system? It's should be quite easy on both *nixes and Windows. That way default value would be from operating system, with possibility to override it in .ini. I believe this may have been the behavior at some point; at least date_default_timezone_get change in PHP 5.4 to no longer includes info from the OS. -- 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 Fri, May 24, 2013 at 12:11 AM, Levi Morrison morrison.l...@gmail.comwrote: 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. I was wondering - why not get time zone info from operating system? It's should be quite easy on both *nixes and Windows. That way default value would be from operating system, with possibility to override it in .ini. I believe this may have been the behavior at some point; at least date_default_timezone_get change in PHP 5.4 to no longer includes info from the OS. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Couldn't we take a page from MySQL's book and have a setup script that prompts the admin for this (much like theirs prompts for a root password). A reminder to run it could be added as a nag at the end of the install; or, perhaps even have it give you these setup prompts at the end of make install. This way, any environment-specific settings we think should be there that don't have obvious defaults, like date.timezone, could be added as prompts in the setup script. This would enable even inexperienced admins to add these settings without cluttering-up the bugs tracker. Thoughts? --Kris
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
On Fri, May 24, 2013 at 1:16 AM, Kris Craig kris.cr...@gmail.com wrote: On Fri, May 24, 2013 at 12:11 AM, Levi Morrison morrison.l...@gmail.comwrote: 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. I was wondering - why not get time zone info from operating system? It's should be quite easy on both *nixes and Windows. That way default value would be from operating system, with possibility to override it in .ini. I believe this may have been the behavior at some point; at least date_default_timezone_get change in PHP 5.4 to no longer includes info from the OS. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Couldn't we take a page from MySQL's book and have a setup script that prompts the admin for this (much like theirs prompts for a root password). A reminder to run it could be added as a nag at the end of the install; or, perhaps even have it give you these setup prompts at the end of make install. This way, any environment-specific settings we think should be there that don't have obvious defaults, like date.timezone, could be added as prompts in the setup script. This would enable even inexperienced admins to add these settings without cluttering-up the bugs tracker. Thoughts? --Kris Another possible idea would be to make it so that you can specify the date.timezone in configure. This would cause make install to automatically set it in php.ini. That might be useful for folks like Daniel who don't like having to do that extra step of manually editing php.ini to avoid throwing warning errors. --Kris
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
On Fri, 2013-05-24 at 01:16 -0700, Kris Craig wrote: Couldn't we take a page from MySQL's book and have a setup script that prompts the admin for this (much like theirs prompts for a root password). A reminder to run it could be added as a nag at the end of the install; or, perhaps even have it give you these setup prompts at the end of make install. This way, any environment-specific settings we think should be there that don't have obvious defaults, like date.timezone, could be added as prompts in the setup script. This would enable even inexperienced admins to add these settings without cluttering-up the bugs tracker. An estimate of 90% of our users who are actually installing PHP themselves are using distribution packages of PHP and not our sources. They expect `[yum|apt-get|...] install php` to be the whole installation process. johannes -- 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 2013-05-24 10:34, Johannes Schlüter wrote: On Fri, 2013-05-24 at 01:16 -0700, Kris Craig wrote: Couldn't we take a page from MySQL's book and have a setup script that prompts the admin for this (much like theirs prompts for a root password). A reminder to run it could be added as a nag at the end of the install; or, perhaps even have it give you these setup prompts at the end of make install. This way, any environment-specific settings we think should be there that don't have obvious defaults, like date.timezone, could be added as prompts in the setup script. This would enable even inexperienced admins to add these settings without cluttering-up the bugs tracker. An estimate of 90% of our users who are actually installing PHP themselves are using distribution packages of PHP and not our sources. They expect `[yum|apt-get|...] install php` to be the whole installation process. Yet it's not uncommon for yum/apt-get/whatever to ask for input (like mentioned MySQL asking for root password). --Leszek -- 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 Fri, 24 May 2013, Leszek Krupiński wrote: On 2013-05-23 22:10, Stas Malyshev wrote: 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. I was wondering - why not get time zone info from operating system? It's should be quite easy on both *nixes and Windows. That way default value would be from operating system, with possibility to override it in .ini. You can't, as the OS doesn't give you the timezone identifier in a portable way. cheers, Derick -- 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 Fri, 24 May 2013, Leszek Krupiński wrote: On 2013-05-24 10:34, Johannes Schlüter wrote: On Fri, 2013-05-24 at 01:16 -0700, Kris Craig wrote: Couldn't we take a page from MySQL's book and have a setup script that prompts the admin for this (much like theirs prompts for a root password). A reminder to run it could be added as a nag at the end of the install; or, perhaps even have it give you these setup prompts at the end of make install. This way, any environment-specific settings we think should be there that don't have obvious defaults, like date.timezone, could be added as prompts in the setup script. This would enable even inexperienced admins to add these settings without cluttering-up the bugs tracker. An estimate of 90% of our users who are actually installing PHP themselves are using distribution packages of PHP and not our sources. They expect `[yum|apt-get|...] install php` to be the whole installation process. Yet it's not uncommon for yum/apt-get/whatever to ask for input (like mentioned MySQL asking for root password). I'm pretty sure apt can read the configuration from their tzdata package to add the correct setting to php.ini: a=`debconf-show tzdata | grep Areas | sed 's/.*\s//'`; b=`debconf-show tzdata | grep Zones/$a | sed 's/.*\s//'`; echo $a/$b However, that is something for distributions to do as each distribution's mechanism is different. cheers, Derick -- 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?
Am 24.05.2013 18:45 schrieb Derick Rethans der...@php.net: On Fri, 24 May 2013, Leszek Krupiński wrote: I was wondering - why not get time zone info from operating system? It's should be quite easy on both *nixes and Windows. That way default value would be from operating system, with possibility to override it in .ini. You can't, as the OS doesn't give you the timezone identifier in a portable way. Couldn´t the default, in the absense of an .ini setting, be to use localtime(), i.e. whatever libc does, with the timezone _identifier_ being some string like OS, System, or Localtime - and we could then also use that identifier in .ini or ini_set to precisely say use the same timezone as all the other libc using programs on this system. best regards Patrick
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
On Fri, 24 May 2013, Patrick Schaaf wrote: Am 24.05.2013 18:45 schrieb Derick Rethans der...@php.net: On Fri, 24 May 2013, Leszek Krupiński wrote: I was wondering - why not get time zone info from operating system? It's should be quite easy on both *nixes and Windows. That way default value would be from operating system, with possibility to override it in .ini. You can't, as the OS doesn't give you the timezone identifier in a portable way. Couldn´t the default, in the absense of an .ini setting, be to use localtime(), i.e. whatever libc does, with the timezone _identifier_ being some string like OS, System, or Localtime - and we could then also use that identifier in .ini or ini_set to precisely say use the same timezone as all the other libc using programs on this system. Absolutely not, as you can then never convert between that and another zone. This nonsense is what Redhat patches into it as well and it is a BAD idea. You'd have no idea which DST rules are cheers, Derick -- 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?
While UTC is not *ideal*, I am failing to see why its not a reasonable default. After all, according to http://us3.php.net/manual/en/function.date-default-timezone-get.php If none of the above succeed, date_default_timezone_get() will return a default timezone of UTC. If people care about dealing with time's in a non-UTC way, it seems to me they they would either A) ensure their server is set to an appropriate timezone (by setting it or bugging their system administrator) or B) ensuring their app calls date_default_timezone_set() in a bootstrap/initialization script (globally) or C) set the timezone in an application context specific way through DateTime::setTimezone(). As far as I can tell, with all standard distribution extensions, there is no other extension that will toss a warning with the default configuration... thus making this the outlier. -ralph On 5/23/13 3:10 PM, Stas Malyshev 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. -- 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?
If none of the above succeed, date_default_timezone_get() will return a
default timezone of UTC.
It will still raise a warning, by the way. This is horrible behavior;
I recommend the following:
date_default_timezone_set(ini_get('date.timezone') ?: 'UTC');
This is basically what date_default_timezone_get does as of PHP 5.4
except there is no warning.
--
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 Fri, May 24, 2013 at 2:40 AM, Derick Rethans der...@php.net wrote: On Thu, 23 May 2013, Daniel Lowrey wrote: 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. No - you, as an admin, are required to make an informed decision on what you want your timezone to be. There have been way too many bug reports where people had no clue, so now we throw a warning. Sorry, but I fail to see why date.timezone needs special handling. What makes the date.timezone setting so important, that it is the only one which value you are required to set? There are settings that are arguably a lot more important than this, but which do not throw such warnings. E.g., why isn't there a warning for cases where error_reporting is not explicitly specified? I can't count the number of StackOverflow questions caused by bad error_reporting settings and I'm very sure this number surpasses complains about timezones by several orders of magnitude. Yet - of course! - we do no such thing, for it is senseless. After all, there *is* a reason why we have defaults for ini settings. People should only be required to changed them when necessary. Date.timezone should be no exception to this. Nikita
[PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
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 result, when I use any of the date/time functionality I invariably end up with this awesomeness: Warning: date(): It is not safe to rely on the system's timezone settings blah blah blah. Could I run `$ php -d date.timezone=UTC myfile.php`? Of course, but should that really be necessary? It seems to me this warning caters to the very lowest common denominator among PHP devs who can't be bothered to understand how PHP handles timezones. The warning also seems to assume that people only use PHP as a web framework and not as an actual programming language (otherwise I wouldn't have to explain to the CLI which timezone I want to use). I don't need php.ini ... I want to use PHP to *program*. If it's going to default to UTC anyway should there really be an E_WARNING? Can't PHP just quietly use UTC? The U in UTC *does* stand for Universal, after all. It's a sensible default and as such shouldn't merit a warning. Besides, if someone doesn't understand what's happening and gets unexpected date/time results the first thing they're going to do (I hope) is hit their favorite search engine for set PHP timezone. Perhaps I'm the only person to experience ongoing annoyance at the hands of this protective feature? Is there a substantive reason why this warning exists other than the error message's suggestion that you most likely misspelled the timezone identifier? I understand that one of PHP's most attractive features is ease-of-use for programming novices but you can only go so far in preventing people who don't know what they're doing from shooting themselves in the foot. I'm not sure if it's possible but perhaps a compromise might be to disable this warning in the CLI, at least? -- 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 Thu, May 23, 2013 at 8:40 PM, Daniel Lowrey rdlow...@gmail.com wrote: 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 result, when I use any of the date/time functionality I invariably end up with this awesomeness: Warning: date(): It is not safe to rely on the system's timezone settings blah blah blah. Could I run `$ php -d date.timezone=UTC myfile.php`? Of course, but should that really be necessary? It seems to me this warning caters to the very lowest common denominator among PHP devs who can't be bothered to understand how PHP handles timezones. The warning also seems to assume that people only use PHP as a web framework and not as an actual programming language (otherwise I wouldn't have to explain to the CLI which timezone I want to use). I don't need php.ini ... I want to use PHP to *program*. If it's going to default to UTC anyway should there really be an E_WARNING? Can't PHP just quietly use UTC? The U in UTC *does* stand for Universal, after all. It's a sensible default and as such shouldn't merit a warning. Besides, if someone doesn't understand what's happening and gets unexpected date/time results the first thing they're going to do (I hope) is hit their favorite search engine for set PHP timezone. Perhaps I'm the only person to experience ongoing annoyance at the hands of this protective feature? Is there a substantive reason why this warning exists other than the error message's suggestion that you most likely misspelled the timezone identifier? I understand that one of PHP's most attractive features is ease-of-use for programming novices but you can only go so far in preventing people who don't know what they're doing from shooting themselves in the foot. I'm not sure if it's possible but perhaps a compromise might be to disable this warning in the CLI, at least? Fully agreed. The warning is very annoying when using CLI. And even when not using CLI: The timezone is usually only relevant in production. I don't care if times are off a few hours when developing stuff. Nikita
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
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
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
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
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
On Thu, 23 May 2013, Daniel Lowrey wrote: 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. No - you, as an admin, are required to make an informed decision on what you want your timezone to be. There have been way too many bug reports where people had no clue, so now we throw a warning. cheers, Derick -- 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 2013-05-23 22:10, Stas Malyshev wrote: 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. I was wondering - why not get time zone info from operating system? It's should be quite easy on both *nixes and Windows. That way default value would be from operating system, with possibility to override it in .ini. --Leszek -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
