On 2 September 2013 12:16, Nikita Popov wrote:
> On Mon, Sep 2, 2013 at 11:47 AM, Derick Rethans wrote:
>
> > On Wed, 28 Aug 2013, Nikita Popov wrote:
> >
> > > On Thu, May 23, 2013 at 8:40 PM, Daniel Lowrey
> > wrote:
> > >
> > > > I'm probably not the typical PHP user; I spend 99% of my PHP t
On Mon, Sep 2, 2013 at 11:47 AM, Derick Rethans wrote:
> On Wed, 28 Aug 2013, Nikita Popov wrote:
>
> > On Thu, May 23, 2013 at 8:40 PM, Daniel Lowrey
> 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 th
On Wed, 28 Aug 2013, Nikita Popov wrote:
> On Thu, May 23, 2013 at 8:40 PM, Daniel Lowrey 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 u
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 war
-DEV] date.timezone E_WARNING -- Really necessary? What's the
rationale?
I agree.
2013/8/28 Nikita Popov
> On Thu, May 23, 2013 at 8:40 PM, Daniel Lowrey wrote:
>
> > I'm probably not the typical PHP user; I spend 99% of my PHP time
> > using the CLI (and not web S
I agree.
2013/8/28 Nikita Popov
> On Thu, May 23, 2013 at 8:40 PM, Daniel Lowrey 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
On Thu, May 23, 2013 at 8:40 PM, Daniel Lowrey 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 e
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
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.
>
>
On Mon, May 27, 2013 at 4:35 PM, Daniel Lowrey 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 f
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
does
On 27 May 2013 09:35, Jannik Zschiesche 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 s
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 a
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 pr
> 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, t
On Mon, May 27, 2013 at 10:35 AM, Jannik Zschiesche wrote:
> 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 sim
Hello,
Am Montag, 27. Mai 2013 um 09:27 schrieb Pierre Joye:
> On Mon, May 27, 2013 at 9:20 AM, Sanford Whiteman
> (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 h
> 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
On Mon, May 27, 2013 at 9:27 AM, Pierre Joye wrote:
> On Mon, May 27, 2013 at 9:20 AM, Sanford Whiteman
> 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
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. Pr
On Mon, May 27, 2013 at 9:20 AM, Sanford Whiteman
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
> 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 s
On Sun, May 26, 2013 at 11:49 PM, 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
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.
hi,
On Mon, May 27, 2013 at 2:45 AM, Sanford Whiteman
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 functio
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
> 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 do
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
--
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
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.
> 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
hi!
On Sun, May 26, 2013 at 9:43 PM, Sanford Whiteman
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 goi
> 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
>> 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 woul
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
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 thi
On 26 May 2013 07:44, Stas Malyshev 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 too
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 n
On Sat, May 25, 2013 at 6:04 PM, Daniel Lowrey 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,
e
> 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
op
On Sat, May 25, 2013 at 5:09 PM, Levi Morrison wrote:
> >> 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
>> 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 plen
On Sat, May 25, 2013 at 9:03 AM, Levi Morrison 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 i
On 25/05/13 14:09, Pierre Joye wrote:
>
> 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 ear
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 apprecia
> 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 L
Am 25.05.2013 14:09, schrieb Pierre Joye:
> On May 25, 2013 12:31 PM, "Tim Starling" 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 actual
On May 25, 2013 12:31 PM, "Tim Starling" 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 be
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
On Fri, May 24, 2013 at 2:40 AM, Derick Rethans 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 infor
> "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_de
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
On Fri, 24 May 2013, Patrick Schaaf wrote:
> Am 24.05.2013 18:45 schrieb "Derick Rethans" :
> >
> > 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
> > > wa
Am 24.05.2013 18:45 schrieb "Derick Rethans" :
>
> 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 possi
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 p
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
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 t
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 ha
On Fri, May 24, 2013 at 1:16 AM, Kris Craig wrote:
>
>
> On Fri, May 24, 2013 at 12:11 AM, Levi Morrison
> 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
On Fri, May 24, 2013 at 12:11 AM, Levi Morrison 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
>>> 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 us
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
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
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 m
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
On Thu, May 23, 2013 at 8:40 PM, Daniel Lowrey 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 e
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
67 matches
Mail list logo
