FAQ
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?

Search Discussions

  • Nikita Popov at May 23, 2013 at 6:48 pm

    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 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
  • Stas Malyshev at May 23, 2013 at 8:10 pm
    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
  • Daniel Lowrey at May 24, 2013 at 12:26 am
    I guess my point is that I don't believe default settings should
    trigger errors. If it's a default setting, it's a default setting.
    Document it and move on. It's then the user's responsibility to define
    that value correctly if he/she wants something other than the default.

    I don't personally see much difference between triggering E_WARNING
    for date.timezone and -- for example -- open_basedir. There's no error
    to tell me that my script can access the entire filesystem without an
    open_basedir setting and that this could be a potential security risk.
    There's no E_WARNING to say that the default memory_limit value is
    128M and that if I want to use more than that I need to define it in
    php.ini. Where does it stop? It seems like an eminently unsustainable
    practice to trigger errors for every possible oops in your .ini file.

    For me, the date.timezone warning has no positive benefit and provides
    real annoyance every single day. Is that the case for others? I can't
    say, that's why I'm complaining on the internals list :)
    On Thu, May 23, 2013 at 4:10 PM, Stas Malyshev wrote:
    Hi!
    I'm probably not the typical PHP user; I spend 99% of my PHP time
    using the CLI (and not web SAPIs).
    This means that I frequently run PHP without an .ini file. As a
    I'm not sure how this follows - CLI is capable of using ini file just
    like the rest of SAPIs. Why not create it?
    The "U" in UTC *does* stand for "Universal," after all. It's a
    sensible default and as such shouldn't
    I don't think it's a sensible default - people don't actually use UTC
    when considering dates. A minority of people can use timezone that
    coincides with UTC, but not very many use actual UTC.
    --
    Stanislav Malyshev, Software Architect
    SugarCRM: http://www.sugarcrm.com/
    (408)454-6900 ext. 227
  • Derick Rethans at May 24, 2013 at 12:40 am

    On Thu, 23 May 2013, Daniel Lowrey wrote:

    I guess my point is that I don't believe default settings should
    trigger errors. If it's a default setting, it's a default setting.
    No - you, as an admin, are required to make an informed decision on what
    you want your timezone to be. There have been way too many bug reports
    where people had no clue, so now we throw a warning.

    cheers,
    Derick
  • Nikita Popov at May 24, 2013 at 9:35 pm

    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 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
  • Daniel Lowrey at May 25, 2013 at 4:04 pm
    This issue is less about date.timezone than being able to run without an ini file.
    This is my complaint. My point of view is that PHP is a programming
    language, not some goofball windows application. Forcing me to use an
    .ini file to be able to program is a real annoyance. And in my humble
    opinion, triggering a warning "because the worst programmers can't
    correctly set a timezone" is a dubious justification. Granted, I don't
    have to answer the bug reports, but how difficult is it to say, "No,
    this is not a bug. Let me google this for you," and close as "Will not
    fix?" People who think a UTC timezone default is a bug are equivalent
    to my grandparents who think the television is broken because they
    don't know how to press the remote control's power button. Please,
    PHP, do we have to accommodate the very lowest common denominator? If
    you don't kick the baby birds out of the nest they'll never learn to
    fly. I get that everyone doesn't agree, but this seems like a
    no-brainer to me.
    On Fri, May 24, 2013 at 5:35 PM, Nikita Popov wrote:
    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 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
  • Nikita Popov at May 25, 2013 at 4:23 pm

    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,
    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
  • Leszek Krupiński at May 24, 2013 at 5:48 am

    On 2013-05-23 22:10, Stas Malyshev wrote:
    The "U" in UTC *does* stand for "Universal," after all. It's a
    sensible default and as such shouldn't
    I don't think it's a sensible default - people don't actually use UTC
    when considering dates. A minority of people can use timezone that
    coincides with UTC, but not very many use actual UTC.
    I was wondering - why not get time zone info from operating system? It's
    should be quite easy on both *nixes and Windows. That way default value
    would be "from operating system", with possibility to override it in .ini.

    --Leszek
  • Levi Morrison at May 24, 2013 at 7:11 am

    The "U" in UTC *does* stand for "Universal," after all. It's a
    sensible default and as such shouldn't
    I don't think it's a sensible default - people don't actually use UTC
    when considering dates. A minority of people can use timezone that
    coincides with UTC, but not very many use actual UTC.
    I was wondering - why not get time zone info from operating system? It's
    should be quite easy on both *nixes and Windows. That way default value
    would be "from operating system", with possibility to override it in .ini.
    I believe this may have been the behavior at some point; at least
    date_default_timezone_get change in PHP 5.4 to no longer includes info
    from the OS.
  • Kris Craig at May 24, 2013 at 8:16 am

    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 can use timezone that
    coincides with UTC, but not very many use actual UTC.
    I was wondering - why not get time zone info from operating system? It's
    should be quite easy on both *nixes and Windows. That way default value
    would be "from operating system", with possibility to override it in
    .ini.

    I believe this may have been the behavior at some point; at least
    date_default_timezone_get change in PHP 5.4 to no longer includes info
    from the OS.

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    Couldn't we take a page from MySQL's book and have a setup script that
    prompts the admin for this (much like theirs prompts for a root password).
      A reminder to run it could be added as a nag at the end of the install;
    or, perhaps even have it give you these setup prompts at the end of make
    install. This way, any environment-specific settings we think should be
    there that don't have obvious defaults, like date.timezone, could be added
    as prompts in the setup script. This would enable even inexperienced
    admins to add these settings without cluttering-up the bugs tracker.

    Thoughts?

    --Kris
  • Kris Craig at May 24, 2013 at 8:20 am
    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 actually use UTC
    when considering dates. A minority of people can use timezone that
    coincides with UTC, but not very many use actual UTC.
    I was wondering - why not get time zone info from operating system? It's
    should be quite easy on both *nixes and Windows. That way default value
    would be "from operating system", with possibility to override it in
    .ini.

    I believe this may have been the behavior at some point; at least
    date_default_timezone_get change in PHP 5.4 to no longer includes info
    from the OS.

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    Couldn't we take a page from MySQL's book and have a setup script that
    prompts the admin for this (much like theirs prompts for a root password).
    A reminder to run it could be added as a nag at the end of the install;
    or, perhaps even have it give you these setup prompts at the end of make
    install. This way, any environment-specific settings we think should be
    there that don't have obvious defaults, like date.timezone, could be added
    as prompts in the setup script. This would enable even inexperienced
    admins to add these settings without cluttering-up the bugs tracker.

    Thoughts?

    --Kris
    Another possible idea would be to make it so that you can specify the
    date.timezone in configure. This would cause make install to automatically
    set it in php.ini. That might be useful for folks like Daniel who don't
    like having to do that extra step of manually editing php.ini to avoid
    throwing warning errors.

    --Kris
  • Johannes Schlüter at May 24, 2013 at 8:32 am

    On Fri, 2013-05-24 at 01:16 -0700, Kris Craig wrote:
    Couldn't we take a page from MySQL's book and have a setup script that
    prompts the admin for this (much like theirs prompts for a root password).
    A reminder to run it could be added as a nag at the end of the install;
    or, perhaps even have it give you these setup prompts at the end of make
    install. This way, any environment-specific settings we think should be
    there that don't have obvious defaults, like date.timezone, could be added
    as prompts in the setup script. This would enable even inexperienced
    admins to add these settings without cluttering-up the bugs tracker.
    An estimate of >90% of our users who are actually installing PHP
    themselves are using distribution packages of PHP and not our sources.
    They expect `[yum|apt-get|...] install php` to be the whole installation
    process.

    johannes
  • Leszek Krupiński at May 24, 2013 at 8:45 am

    On 2013-05-24 10:34, Johannes Schlüter wrote:
    On Fri, 2013-05-24 at 01:16 -0700, Kris Craig wrote:
    Couldn't we take a page from MySQL's book and have a setup script that
    prompts the admin for this (much like theirs prompts for a root password).
    A reminder to run it could be added as a nag at the end of the install;
    or, perhaps even have it give you these setup prompts at the end of make
    install. This way, any environment-specific settings we think should be
    there that don't have obvious defaults, like date.timezone, could be added
    as prompts in the setup script. This would enable even inexperienced
    admins to add these settings without cluttering-up the bugs tracker.
    An estimate of >90% of our users who are actually installing PHP
    themselves are using distribution packages of PHP and not our sources.
    They expect `[yum|apt-get|...] install php` to be the whole installation
    process.
    Yet it's not uncommon for yum/apt-get/whatever to ask for input (like
    mentioned MySQL asking for root password).

    --Leszek
  • Derick Rethans at May 24, 2013 at 4:53 pm

    On Fri, 24 May 2013, Leszek Krupiński wrote:
    On 2013-05-24 10:34, Johannes Schlüter wrote:
    On Fri, 2013-05-24 at 01:16 -0700, Kris Craig wrote:
    Couldn't we take a page from MySQL's book and have a setup script that
    prompts the admin for this (much like theirs prompts for a root password).
    A reminder to run it could be added as a nag at the end of the install;
    or, perhaps even have it give you these setup prompts at the end of make
    install. This way, any environment-specific settings we think should be
    there that don't have obvious defaults, like date.timezone, could be added
    as prompts in the setup script. This would enable even inexperienced
    admins to add these settings without cluttering-up the bugs tracker.
    An estimate of >90% of our users who are actually installing PHP
    themselves are using distribution packages of PHP and not our sources.
    They expect `[yum|apt-get|...] install php` to be the whole installation
    process.
    Yet it's not uncommon for yum/apt-get/whatever to ask for input (like
    mentioned MySQL asking for root password).
    I'm pretty sure apt can read the configuration from their "tzdata"
    package to add the correct setting to php.ini:

      a=`debconf-show tzdata | grep Areas | sed 's/.*\s//'`; b=`debconf-show tzdata | grep Zones/$a | sed 's/.*\s//'`; echo "$a/$b"

    However, that is something for distributions to do as each
    distribution's mechanism is different.

    cheers,
    Derick
  • Derick Rethans at May 24, 2013 at 4:45 pm

    On Fri, 24 May 2013, Leszek Krupiński wrote:
    On 2013-05-23 22:10, Stas Malyshev wrote:
    The "U" in UTC *does* stand for "Universal," after all. It's a
    sensible default and as such shouldn't
    I don't think it's a sensible default - people don't actually use UTC
    when considering dates. A minority of people can use timezone that
    coincides with UTC, but not very many use actual UTC.
    I was wondering - why not get time zone info from operating system? It's
    should be quite easy on both *nixes and Windows. That way default value would
    be "from operating system", with possibility to override it in .ini.
    You can't, as the OS doesn't give you the timezone identifier in a
    portable way.

    cheers,
    Derick
  • Patrick Schaaf at May 24, 2013 at 6:15 pm

    Am 24.05.2013 18:45 schrieb "Derick Rethans" <derick@php.net>:
    On Fri, 24 May 2013, Leszek Krupiński wrote:

    I was wondering - why not get time zone info from operating system? It's
    should be quite easy on both *nixes and Windows. That way default value
    would
    be "from operating system", with possibility to override it in .ini.
    You can't, as the OS doesn't give you the timezone identifier in a
    portable way.
    Couldn´t the default, in the absense of an .ini setting, be to use
    localtime(), i.e. whatever libc does, with the timezone _identifier_ being
    some string like "OS", "System", or "Localtime" - and we could then also
    use that identifier in .ini or ini_set to precisely say "use the same
    timezone as all the other libc using programs on this system".

    best regards
       Patrick
  • Derick Rethans at May 24, 2013 at 6:23 pm

    On Fri, 24 May 2013, Patrick Schaaf wrote:

    Am 24.05.2013 18:45 schrieb "Derick Rethans" <derick@php.net>:
    On Fri, 24 May 2013, Leszek Krupiński wrote:

    I was wondering - why not get time zone info from operating
    system? It's should be quite easy on both *nixes and Windows. That
    way default value would be "from operating system", with
    possibility to override it in .ini.
    You can't, as the OS doesn't give you the timezone identifier in a
    portable way.
    Couldn´t the default, in the absense of an .ini setting, be to use
    localtime(), i.e. whatever libc does, with the timezone _identifier_
    being some string like "OS", "System", or "Localtime" - and we could
    then also use that identifier in .ini or ini_set to precisely say "use
    the same timezone as all the other libc using programs on this
    system".
    Absolutely not, as you can then never convert between that and another
    zone. This nonsense is what Redhat patches into it as well and it is a
    BAD idea. You'd have no idea which DST rules are

    cheers,
    Derick
  • Ralph Schindler at May 24, 2013 at 6:52 pm
    While UTC is not *ideal*, I am failing to see why its not a reasonable
    default. After all, according to

    http://us3.php.net/manual/en/function.date-default-timezone-get.php

    "If none of the above succeed, date_default_timezone_get() will return a
    default timezone of UTC."

    If people care about dealing with time's in a non-UTC way, it seems to
    me they they would either A) ensure their server is set to an
    appropriate timezone (by setting it or bugging their system
    administrator) or B) ensuring their app calls
    date_default_timezone_set() in a bootstrap/initialization script
    (globally) or C) set the timezone in an application context specific way
    through DateTime::setTimezone().

    As far as I can tell, with all standard distribution extensions, there
    is no other extension that will toss a warning with the default
    configuration... thus making this the outlier.

    -ralph
    On 5/23/13 3:10 PM, Stas Malyshev wrote:
    Hi!
    I'm probably not the typical PHP user; I spend 99% of my PHP time
    using the CLI (and not web SAPIs).
    This means that I frequently run PHP without an .ini file. As a
    I'm not sure how this follows - CLI is capable of using ini file just
    like the rest of SAPIs. Why not create it?
    The "U" in UTC *does* stand for "Universal," after all. It's a
    sensible default and as such shouldn't
    I don't think it's a sensible default - people don't actually use UTC
    when considering dates. A minority of people can use timezone that
    coincides with UTC, but not very many use actual UTC.
  • Levi Morrison at May 24, 2013 at 7:18 pm

    "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.
  • Richard Lynch at May 30, 2013 at 1:19 am

    On Thu, May 23, 2013 3:10 pm, Stas Malyshev wrote:
    I'm probably not the typical PHP user; I spend 99% of my PHP time
    using the CLI (and not web SAPIs).
    This means that I frequently run PHP without an .ini file. As a
    I'm not sure how this follows - CLI is capable of using ini file just
    like the rest of SAPIs. Why not create it?
    The "U" in UTC *does* stand for "Universal," after all. It's a
    sensible default and as such shouldn't
    I don't think it's a sensible default - people don't actually use UTC
    when considering dates. A minority of people can use timezone that
    coincides with UTC, but not very many use actual UTC.
    I don't know about everybody else, but if I need a timezone-aware
    application, I always use GMT/UTC and have I/O routines for
    user-interface to convert to local for them.
  • Tim Starling at May 25, 2013 at 10:31 am

    On 23/05/13 20:40, Daniel Lowrey wrote:
    If it's going to default to UTC anyway should there really be an
    E_WARNING? Can't PHP just quietly use UTC? The "U" in UTC *does*
    stand for "Universal," after all. It's a sensible default and as
    such shouldn't merit a warning.
    Actually, the sensible default is what guess_timezone() does already,
    except without the warnings. You can get that behaviour with e.g.

    date_default_timezone_set( @date_default_timezone_get() );

    at the top of your program. That's what MediaWiki does (except with by
    modifying error_reporting instead of using @). We stole the idea from
    another web app. It's more convenient than duplicating the
    functionality of guess_timezone() in the application.

    It's Derick's prerogative to annoy all users half to death with
    warnings, as his way of indicating his distaste for the state of OS
    support for querying of system timezone. That's the reward we give him
    for writing lots of date/time code.

    -- Tim Starling
  • Pierre Joye at May 25, 2013 at 12:09 pm
    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 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.
  • Pierre Schmitz at May 25, 2013 at 12:30 pm

    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 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
  • Paul Reinheimer at May 25, 2013 at 3:03 pm
    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
  • Levi Morrison at May 25, 2013 at 3:03 pm

    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.
  • Levi Morrison at May 25, 2013 at 3:06 pm

    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 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.
  • Stas Malyshev at May 26, 2013 at 6:44 am
    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
  • Richard Quadling at May 26, 2013 at 11:42 am

    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 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
  • Lester Caine at May 26, 2013 at 11:50 am

    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
  • Tim Starling at May 26, 2013 at 1:17 pm

    On 26/05/13 13:50, Lester Caine wrote:
    Richard Quadling wrote:
    As more and more site/services are being hosted in the cloud, allowing
    requests to be handled locally geographically, in different
    timezones, does
    it make ANY sense in setting a timezone at all other than UTC?
    This is something I have been saying all along. The whole thing is
    broken anyway since you have no idea what time-zone a USER is
    accessing from since the browser bodge only provides a current time
    offset. Until a user logs into a site and provides the data of their
    current daylight saving 'location' anything else is a guess. If you
    are assuming a server is in a single time-zone, then it makes even
    less sense to use anything other than UTC and ignore timezones
    altogether?
    If you're writing a CLI script which produces timestamped log lines on
    stdout, it probably makes sense to use the TZ environment variable,
    and to fall back to /usr/share/zoneinfo if it is unset, like localtime().

    If you're writing a web app which writes timestamped log lines to a
    local file, it probably makes sense to use whatever timezone is
    specified in /usr/share/zoneinfo, for consistency with syslogd etc.

    For timestamps sent to web app end users, you probably want it to be
    user configurable with UTC as the default, or use some local time for
    websites with geographically limited interest. It's likely that the
    timezone of maximum user interest will be different from the server
    timezone, so it doesn't really make sense to couple the two.

    In none of these cases does it make sense to require the sysadmin to
    set a timezone in php.ini before even being able to use the app, so I
    don't understand why that is the policy chosen by PHP. But like I said
    in my original post, I really don't mind: thank you for writing
    ext/datetime, please continue annoying users to whatever extent you
    see fit.

    -- Tim Starling
  • Sanford Whiteman at May 26, 2013 at 7:44 pm

    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
  • Pierre Joye at May 26, 2013 at 10:56 pm
    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 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
  • Sanford Whiteman at May 27, 2013 at 12:46 am

    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.
  • Kris Craig at May 27, 2013 at 3:28 am
    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" wrote:

    Then set the TZ to UTC or whatever else fits your needs. Server side
    TZ from a php point of view can be set to whatever you want, be at the
    php.ini level or in your application configuration (and call the
    appropriate function).
    Was there something that indicated I don't know how to do this? I have
    always done it and have no problem with it. I don't mind how it works
    now at all.

    Lester's point is UTC is the right default (and thus the battle over
    the E_WARNING should be settled that way). I happen to agree with that
    part, but disagree from heavy experience with the notion that "UTC or
    end-user-selectable" is the only choice you have once you set a value.
    Let the user has an option and use this option to set the right TZ at
    the beginning of each request. That's what every tool I know does.
    (a) You don't know all the tools in the world.

    (b) Please show me how every major web app gives you a clearly visible
    and encouraged option to set the tz _at the beginning of each session_
    (I don't think you mean request). Happy to send screenshots to the
    contrary.

    (c) When a web app lets the user change her/his profile parameters
    (which is certainly common) this is irrelevant to their session (so if
    they change it when they're in City A, they have to change it again in
    City B and C as they jump around), (b) on an advanced setup tab
    somewhere.

    You're dead wrong if you think traveling telecommuters are always
    looking at -- let alone want to look at -- their local time.
    That being said, I do not knwow which apps you use to organize your
    time plans but all we used here do the conversion for you. Users
    hate, me included, to have meetings and other time related
    activities notifications using a different TZ that the one where I
    am (which can change).
    Well... that's not the way every set of organizations work, hate to
    break it to ya. For some apps the Chennai office is at least in part
    on San Francisco time. This can be because they remote in and don't
    constantly set the TZ in their Citrix session, or because they use a
    web app and, like most real users, can't be bothered to find the
    setting and are not in any way nagged to do so.

    This doesn't mean that some scheduler app doesn't display their local
    time _as well_ as the origin time. But have you ever seen the ol' wall
    of world clocks? There's a reason for that. I like to work that way
    and so to lots of humans.
    Then do it this way:
    - default in php.ini
    - override default is an user has his TZ option set
    I don't need these instructions, which are quite condescending. (And
    if you think *I* need them, how can this coexist with the fantasy that
    non-programmers always tightly manage their TZ?)

    -- S.





    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Reinis Rozitis at May 27, 2013 at 6:49 am

    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
  • Leszek Krupiński at May 27, 2013 at 6:57 am

    On 2013-05-27 08:49, Reinis Rozitis wrote:
    Again, why can't we just bypass this whole argument by adding a configure
    option? Something like --date.default_timezone="America/Los_Angeles"? It
    could then build that in so it'll assume that if there's no php.ini or if
    it's just not set in there. Problem solved, everybody's use-case covered.
    If you build php yourself from source there is always the option to throw
    (comment out) that one particular E_WARNING line ext/date/php_date.c.(that
    is something I do for example for mysqlnd which complains about non-existing
    character set on older sphinxsearch instances).
    Doing that kind of modification is a straight way to introducing "custom
    bugs" ;) Having a community-approved setting is something different.
    But if the OP is annoyed by typing "php -d date.timezone=... myfile.php"
    each time he could just make an alias (or doskey in win environment).
    ...and in all #! headers, and in all other places. That could be a
    temporary bypass, not a complete solution.

    l.
  • Kris Craig at May 27, 2013 at 7:02 am

    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's just not set in there. Problem solved, everybody's use-case covered.
    If you build php yourself from source there is always the option to throw
    (comment out) that one particular E_WARNING line ext/date/php_date.c.(that
    is something I do for example for mysqlnd which complains about
    non-existing character set on older sphinxsearch instances).


    But if the OP is annoyed by typing "php -d date.timezone=... myfile.php"
    each time he could just make an alias (or doskey in win environment).


    rr

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    Well yes, but you could make the same argument for a lot of the configure
    options that are already in place. Personally, if such a configure option
    existed, I'd probably use it myself, since date.timezone is generally the
    only manual modification I have to make to php.ini, anyway. If I could set
    that in configure, I wouldn't have to bother with php.ini at all when doing
    installs.

    If there's no downside to adding that option (at least I haven't seen
    anybody offer one yet) and it has a reasonable use-case (which it does),
    then why not? It would certainly make a lot more sense than manually
    editing the source code, particularly for sysadmins who might not have any
    programming experience.

    --Kris
  • Pierre Joye at May 27, 2013 at 6:32 am
    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 function).
    Was there something that indicated I don't know how to do this? I have
    always done it and have no problem with it. I don't mind how it works
    now at all.

    Lester's point is UTC is the right default (and thus the battle over
    the E_WARNING should be settled that way). I happen to agree with that
    part, but disagree from heavy experience with the notion that "UTC or
    end-user-selectable" is the only choice you have once you set a value.
    Let the user has an option and use this option to set the right TZ at
    the beginning of each request. That's what every tool I know does.
    (a) You don't know all the tools in the world.
    That's right. But I really don't want to use an app unable to deal with TZ :)
    (b) Please show me how every major web app gives you a clearly visible
    and encouraged option to set the tz _at the beginning of each session_
    (I don't think you mean request). Happy to send screenshots to the
    contrary.
    Exchange, OpenExchange or almost all calendar/planning oriented apps.

    I do mean request not session. PHP scripts live within a request, some
    settings can be set at the beginning of each request (how per host/dir
    setting works). A session is a set of multiple requests. However an
    app may store some session related data in a session.
    (c) When a web app lets the user change her/his profile parameters
    (which is certainly common) this is irrelevant to their session (so if
    they change it when they're in City A, they have to change it again in
    City B and C as they jump around), (b) on an advanced setup tab
    somewhere.
    Yes, that's what everyone I work with does and has to to do loose
    their mind with manual conversions.
    You're dead wrong if you think traveling telecommuters are always
    looking at -- let alone want to look at -- their local time.
    Different experience.
    That being said, I do not knwow which apps you use to organize your
    time plans but all we used here do the conversion for you. Users
    hate, me included, to have meetings and other time related
    activities notifications using a different TZ that the one where I
    am (which can change).
    Well... that's not the way every set of organizations work, hate to
    break it to ya. For some apps the Chennai office is at least in part
    on San Francisco time. This can be because they remote in and don't
    constantly set the TZ in their Citrix session, or because they use a
    web app and, like most real users, can't be bothered to find the
    setting and are not in any way nagged to do so.
    It seems that you are confused between client TZ and server TZ. Also
    it seems that there is also confusion between displaying time and
    storing time. Nothing prevent an app to store time data using a given
    TZ and display it using the relevant TZ,
    This doesn't mean that some scheduler app doesn't display their local
    time _as well_ as the origin time. But have you ever seen the ol' wall
    of world clocks? There's a reason for that. I like to work that way
    and so to lots of humans.
    Then do it this way:
    - default in php.ini
    - override default is an user has his TZ option set
    I don't need these instructions, which are quite condescending. (And
    if you think *I* need them, how can this coexist with the fantasy that
    non-programmers always tightly manage their TZ?)
    I can't do anything but tell some advises, I'm sorry if you take them
    as condescending, they are not. It is only about technical and design
    questions, we discuss them, exchange ideas or solutions, that's it.

    That being said, all these points are not really relevant here. This
    thread is all about avoiding adding one line to a php.ini for the lazy
    one, or one call to a date function. If an application is hardly
    linked to a given TZ then a php.ini default is strongly recommended,
    no default TZ will ever help here.

    Cheers,
    --
    Pierre

    @pierrejoye | http://www.libgd.org
  • Stas Malyshev at May 27, 2013 at 3:31 am
    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
  • Sanford Whiteman at May 27, 2013 at 5:11 am

    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.
  • Leszek Krupiński at May 27, 2013 at 6:28 am

    On 2013-05-27 07:10, Sanford Whiteman wrote:
    In general, I use the principle of "domain time." If a site serves a
    (stock) exchange that closes at 4:00pm Eastern time, people hitting
    that site from all over the world are not going to necessarily
    remember that close-of-business is such-and-such UTC or such-and-such
    Tokyo. At best they will need to see the times side-by-side (like the
    example of world clocks on the wall). And the fact that our clients'
    end users see the time at corporate HQ by default is just another
    manifestation of the domain time principle. Some domains don't pretend
    to be timeless and spaceless. Note this doesn't mean all client
    software is ignoring "roaming time" -- we send iCal invites in UTC of
    course -- nor that, in our case, users they can't change what the site
    displays if they insist (though they rarely do). It's a question of
    the best-fit default.

    Of course, there are many sites for which the best default *is*
    user-defined or UTC, whichever is found first. It's just not a
    universal assumption.
    As you have said - there are some use cases, where non-UTC TZ setting is
    important. But do you think that people running this software wouldn't
    know that they have to set a proper time zone in ini file? Or at least
    in app configuration? In my opinion UTC is a good compromise. From my
    experience, the problem divides into two categories:
    a) apps that display time on pages and users might be wondering why the
    time has some shift - it's not a critical setting; it might be set, but
    without this no key features are borked;
    b) app is deeply set in a geographic location, like aforementioned stock
    exchange - proper setting is critical.

    In a) setting TZ to UTC is not making the website broken - it's just a
    glitch. Admin can fix the setting if anyone notices the problem - yes,
    that might stem a lot of bug reports, but as it was with
    register_globals. In b) admin should really know better that he has to
    set this in ini.

    Also, in my opinion, responsibility for the setting should be moved from
    system administrator to application developer. If app is time-set, it
    should have a proper setting for this.

    It was said before that there aren't many systems that require you to
    set this setting. It was also bashed that "you don't know all the apps".
    Yeah, maybe I don't know all of them, but I've installed Python, Ruby
    and Java apps (which I assume comprise most of web app environments -
    ASP aside, but I suppose in this case it's even easier to get proper TZ
    from environment), and I was never forced to set _any_ option because
    otherwise my app would be showing some nasty warnings. But that's only
    my experience.

    --Leszek
  • Sanford Whiteman at May 27, 2013 at 7:20 am
    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.
  • Pierre Joye at May 27, 2013 at 7:27 am

    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 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
  • Nikita Popov at May 27, 2013 at 8:01 am

    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 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
  • Jannik Zschiesche at May 27, 2013 at 8:35 am
    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-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

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Leszek Krupinski at May 27, 2013 at 8:52 am

    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 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
  • Peter Cowburn at May 27, 2013 at 7:05 pm

    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 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
  • Jannik Zschiesche at May 28, 2013 at 8:26 am
    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
  • Lester at May 27, 2013 at 8:15 am
    In my opinion UTC is a good compromise.
    I agree that _in the absence of any other setting_ there's nothing
    wrong with using UTC! Let be clear: UTC is a perfectly fine hands-off
    default rather than issuing a warning. Non-technical end users will
    guess you're on London time but whatever.

    And if you think 'London time' is UTC then you will get just as many problems half of tbe year. Once one is WORKING using timezones, you need to actually understand that for some timezones, the time will be an hour different for half of the year and simply assuming that the time offset from the browser is correct is as bad as assuming UTC is London time.

    The many problems being tributed to automatically setting a server timezone were always more due to understanding that the server was getting things like daylight saving wrong. Set the server to UTC and then select a DISPLAY timezone makes managing time a lot easier. Add to that the option to user a client set timezone and one is good to go ....

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Sanford Whiteman at May 27, 2013 at 9:00 am

    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.

Related Discussions

People

Translate

site design / logo © 2017 Grokbase