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?
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
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
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 :)
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 aI'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'tI 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
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
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
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.
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
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
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
The "U" in UTC does stand for "Universal," after all. It's a
sensible default and as such shouldn'tI 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.
On Fri, May 24, 2013 at 12:11 AM, Levi Morrison morrison.levi@gmail.comwrote:
The "U" in UTC does stand for "Universal," after all. It's a
sensible default and as such shouldn'tI 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.--
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
On Fri, May 24, 2013 at 12:11 AM, Levi Morrison morrison.levi@gmail.comwrote:
The "U" in UTC does stand for "Universal," after all. It's a
sensible default and as such shouldn'tI 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.--
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
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
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 phpto 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
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 phpto 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
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
Am 24.05.2013 18:45 schrieb "Derick Rethans" derick@php.net:
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
Am 24.05.2013 18:45 schrieb "Derick Rethans" derick@php.net:
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
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
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 aI'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'tI 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.
"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.
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 aI'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'tI 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.
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
.
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.
Am 25.05.2013 14:09, schrieb Pierre Joye:
.
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
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
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.
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.
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
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
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
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
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.
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, yeah, but they're collaborating with
people in the US timezone and they don't want to face constant offsets
and am/pm confusion whenever they log in. Even subcontractors
permanently residing in another city are usually better off with the
HQ timezone, because they are racing to submit stuff by HQ's close of
business, not their own (which could be three business days later).
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. 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.
As Tim and Richard said, the "most interesting" timezone has no
intrinsic relationship to the server timezone given cloud
computing/colocation.
Anyway, the problems raised on this thread have made me think more
about how we let users handle time, so I appreciate the discussion and
may change my take over the next few days.
-- Sandy
hi!
On Sun, May 26, 2013 at 9:43 PM, Sanford Whiteman
swhitemanlistens-software@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
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.
Again, why can't we just bypass this whole argument by adding a configure
option? Something like --date.default_timezone="America/Los_Angeles"? It
could then build that in so it'll assume that if there's no php.ini or if
it's just not set in there. Problem solved, everybody's use-case covered.
--Kris
On May 26, 2013 5:46 PM, "Sanford Whiteman" <
swhitemanlistens-software@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
theE_WARNINGshould 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.
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
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 particularE_WARNINGline 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.
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 particularE_WARNINGline 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
--
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
hi,
On Mon, May 27, 2013 at 2:45 AM, Sanford Whiteman
swhitemanlistens-software@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
theE_WARNINGshould 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
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
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.
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
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.
On Mon, May 27, 2013 at 9:20 AM, Sanford Whiteman
swhitemanlistens-software@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
On Mon, May 27, 2013 at 9:20 AM, Sanford Whiteman
swhitemanlistens-software@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
Hello,
Am Montag, 27. Mai 2013 um 09:27 schrieb Pierre Joye:
On Mon, May 27, 2013 at 9:20 AM, Sanford Whiteman
<swhitemanlistens-software@cypressintegrated.com (mailto:swhitemanlistens-software@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
On Mon, May 27, 2013 at 10:35 AM, Jannik Zschiesche hello@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
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
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
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 ....
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.
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
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
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?
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
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.
-- Tim Starling
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.
On Sat, May 25, 2013 at 5:09 PM, Levi Morrison morrison.levi@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
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
I agree.
2013/8/28 Nikita Popov nikita.ppv@gmail.com
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
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:ceceldada@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.ppv@gmail.com
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
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
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
On Thu, May 23, 2013 at 8:40 PM, Daniel Lowrey rdlowrey@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
On Thu, May 23, 2013 at 8:40 PM, Daniel Lowrey rdlowrey@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