Uploaded image for project: 'phpBB3'
  1. phpBB3
  2. PHPBB3-7729

Prevent date/time functions from throwing E_WARNING on PHP 5.3 by setting a default timezone

    Details

    • Type: Bug
    • Status: Unverified Fix
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 3.0.x, 3.0.8
    • Fix Version/s: 3.0.9-RC3
    • Component/s: Other
    • Labels:
      None
    • Environment:
      PHP Environment: 6.0.0-dev
      Database: MySQL 6.0.4-alfa

      Description

      Hi,

      I'm getting this bug:

       
      Strict Standards: date() [function.date]: It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Helsinki' for '3.0/DST' instead in E:\wamp\www\forum\index.php on line 83
       
      Strict Standards: getdate() [function.getdate]: It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Helsinki' for '3.0/DST' instead in E:\wamp\www\forum\index.php on line 83
       
      
      

      I have vanilla files, including common.php with no changes.

      This bug does not show with php 5.2.6 couse have by deafult in php.ini

      error_reporting = E_ALL & ~E_NOTICE

      However php.ini with php 6.0.0-dev has by default:

      error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT

      The issue apears when we switch back to php5 with Wamp 2.0c wich is keeping this line from php6, so can not be solved in a development enviroment when we have to use deafult settings to code using new Guid Lines.

      To reproduce this you have to download from sf.net or wampserver.com the folowing files:

      WampServer2.0c.exe
      WampServer2-PHP6.0dev.exe
      WampServer2-MYSQL604alpha.exe (optional)

      On Vista install wamp on your spare drive so you have priviledges to the drive root.

      After all is installed and if you configured mysql users to have acces from any ip optionaly you can add add same priviledges to apache so that the test site can be accessed from a external ip to the lan.
      For this open: httpd.conf

      Find:
      Order Deny,Allow
      Deny from all
      Allow from 127.0.0.1
      Replace with:
      #Order Deny,Allow
      #Deny from all
      #Allow from 127.0.0.1
      Order allow,deny
      Allow from all

      I think this should be fixed when untill php6 is gold...

        Issue Links

          Activity

          Hide
          bantu Andreas Fischer added a comment - - edited

          The errors generated by PHP 5.3 are of type E_WARNING and are not startup errors but are generated when calling date() and even date_default_timezone_get() throws it.

          Show
          bantu Andreas Fischer added a comment - - edited The errors generated by PHP 5.3 are of type E_WARNING and are not startup errors but are generated when calling date() and even date_default_timezone_get() throws it.
          Hide
          bantu Andreas Fischer added a comment -

          The E_WARNING also explains why we see this so often (in support etc.) because we do indeed show E_WARNING errors.

          Show
          bantu Andreas Fischer added a comment - The E_WARNING also explains why we see this so often (in support etc.) because we do indeed show E_WARNING errors.
          Hide
          bantu Andreas Fischer added a comment -

          It's also E_WARNING in the PHP 5.4 branch and trunk.

          Show
          bantu Andreas Fischer added a comment - It's also E_WARNING in the PHP 5.4 branch and trunk.
          Hide
          bantu Andreas Fischer added a comment -

          It's E_STRICT on PHP 5.2.

          Show
          bantu Andreas Fischer added a comment - It's E_STRICT on PHP 5.2.
          Hide
          Oleg Oleg [X] (Inactive) added a comment - - edited

          It seems that using date class, as we are planning for 3.1, upgrades the warning to a fatal error:

          PHP Fatal error: Uncaught exception 'Exception' with message 'DateTime::__construct(): It is not safe to rely on the system's timezone settings. You are required to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead' in .../forums/includes/session.php:2127

          Code in question:

                  function get_timezone_offset($gmepoch)
                  {
                          return $this->get_timezone_object()->getOffset(new DateTime('@' . $gmepoch));
                  }
          

          No action is needed now, however the comment above date_default_timezone_set(date_default_timezone_get()) might need to be adjusted when the timezone handling is implemented.

          Also, at least on my system I only got the description and not the words "fatal error" so as usual there is an opportunity to waste a fair amount of time figuring out what is going on, especially coming in with an expectation that the problem is a warning which is not fatal.

          Show
          Oleg Oleg [X] (Inactive) added a comment - - edited It seems that using date class, as we are planning for 3.1, upgrades the warning to a fatal error: PHP Fatal error: Uncaught exception 'Exception' with message 'DateTime::__construct(): It is not safe to rely on the system's timezone settings. You are required to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'UTC' for 'UTC/0.0/no DST' instead' in .../forums/includes/session.php:2127 Code in question: function get_timezone_offset($gmepoch) { return $this->get_timezone_object()->getOffset(new DateTime('@' . $gmepoch)); } No action is needed now, however the comment above date_default_timezone_set(date_default_timezone_get()) might need to be adjusted when the timezone handling is implemented. Also, at least on my system I only got the description and not the words "fatal error" so as usual there is an opportunity to waste a fair amount of time figuring out what is going on, especially coming in with an expectation that the problem is a warning which is not fatal.

            People

            • Assignee:
              bantu Andreas Fischer
              Reporter:
              orynider Florin Bodin [X] (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development