Moodle
  1. Moodle
  2. MDL-26753 DST issues
  3. MDL-22625

Constant warnings when timezone isn't set properly in php.ini or date_default_timezone_set

    Details

    • Type: Sub-task Sub-task
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: STABLE backlog
    • Component/s: Libraries
    • Labels:
    • Affected Branches:
      MOODLE_20_STABLE
    • Rank:
      16371

      Description

      See http://au2.php.net/manual/en/function.date-default-timezone-set.php

      We should probably make the admin choose a correct timezone name, and also start making Moodle load all the timezone names automatically.

      But for now, we just need a hack to stop the warnings, since times work fine anyway.

        Issue Links

          Activity

          Hide
          Martin Dougiamas added a comment -

          This seems like the right kind of kludge:

          if (function_exists("date_default_timezone_set") and function_exists("date_default_timezone_get"))

          { @date_default_timezone_set(@date_default_timezone_get()); }
          Show
          Martin Dougiamas added a comment - This seems like the right kind of kludge: if (function_exists("date_default_timezone_set") and function_exists("date_default_timezone_get")) { @date_default_timezone_set(@date_default_timezone_get()); }
          Hide
          Martin Dougiamas added a comment -

          I committed this to lib/setup.php to avoid the warnings.

          Show
          Martin Dougiamas added a comment - I committed this to lib/setup.php to avoid the warnings.
          Hide
          Jordan Tomkinson added a comment -

          Sometime after PHP 5.3.0 date_default_timezone_get now returns a fatal error if it cannot obtain the system timezone instead of just a warning
          this results in a blank moodle page with absolutely no errors/warning/hints as to the problem in either moodle debug or apache error log.

          We should require the timezone be set during installation or as a value in config.php
          At the very least it should be documented that moodle will fail without an error if the timezone is not set and the system time is unable to be obtained

          Show
          Jordan Tomkinson added a comment - Sometime after PHP 5.3.0 date_default_timezone_get now returns a fatal error if it cannot obtain the system timezone instead of just a warning this results in a blank moodle page with absolutely no errors/warning/hints as to the problem in either moodle debug or apache error log. We should require the timezone be set during installation or as a value in config.php At the very least it should be documented that moodle will fail without an error if the timezone is not set and the system time is unable to be obtained
          Hide
          David Mudrak added a comment -

          We could add a default call of date_default_timezone_set() to config.php templates. It is already mentioned in config-dist.php but we should add it to config.php generated by installers, too. Hiding the error here is not nice, really. If Moodle crashes with white screen of dead without any info in error.log (even in debugging mode on), it is very difficult to debug it for admins.

          Show
          David Mudrak added a comment - We could add a default call of date_default_timezone_set() to config.php templates. It is already mentioned in config-dist.php but we should add it to config.php generated by installers, too. Hiding the error here is not nice, really. If Moodle crashes with white screen of dead without any info in error.log (even in debugging mode on), it is very difficult to debug it for admins.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          NOTE: This issue was assigned to the STABLE backlog without complete triaging process. Marking it as triaged, but with this note for future reference.

          Show
          Eloy Lafuente (stronk7) added a comment - NOTE: This issue was assigned to the STABLE backlog without complete triaging process. Marking it as triaged, but with this note for future reference.
          Hide
          Jordan Tomkinson added a comment -

          bump for justice

          Show
          Jordan Tomkinson added a comment - bump for justice
          Hide
          Eloy Lafuente (stronk7) added a comment -

          I think we should do the timezone selection mandatory on install, ending in CFG->timezone, and being used by: date_default_timezone_set() in setup.php

          But that means that we should rebuild all out own TZ/DST stuff to use the 100% built-in alternative. It really shouldn't be complex (far simpler and quicker than current moodle implementation). But 2.0.x doesn't seem like a good place to do so.

          Alternatively... without involving the complete switch, for sites having one correct CFG->timezone (Australia/Perth...), we could use it, for the rest we could get the 1st timezone available for the country or so... in fact it doesn't matter much because we are always storing timestamps in DB. And those are independent of that date_default_timezone_set() thing. 100%.

          But in the long term... we must switch completely... just guessing how many cpu cycles are we spending on each time calculation... sure that a lot, the algorithms are really heavy.

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - I think we should do the timezone selection mandatory on install, ending in CFG->timezone, and being used by: date_default_timezone_set() in setup.php But that means that we should rebuild all out own TZ/DST stuff to use the 100% built-in alternative. It really shouldn't be complex (far simpler and quicker than current moodle implementation). But 2.0.x doesn't seem like a good place to do so. Alternatively... without involving the complete switch, for sites having one correct CFG->timezone (Australia/Perth...), we could use it, for the rest we could get the 1st timezone available for the country or so... in fact it doesn't matter much because we are always storing timestamps in DB. And those are independent of that date_default_timezone_set() thing. 100%. But in the long term... we must switch completely... just guessing how many cpu cycles are we spending on each time calculation... sure that a lot, the algorithms are really heavy. Ciao
          Hide
          Martin Dougiamas added a comment -

          We should at least look at http://www.php.net/manual/en/function.date-default-timezone-set.php and examine what the scope of switching to the new built-in functions might be. I'm not convinced yet that it won't have its own new problems.

          Show
          Martin Dougiamas added a comment - We should at least look at http://www.php.net/manual/en/function.date-default-timezone-set.php and examine what the scope of switching to the new built-in functions might be. I'm not convinced yet that it won't have its own new problems.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          +1 to create one small tzlib, for all the date/time operations needed (fully tested, asking for all sort of crazy stuff, checking for results via WS somewhere...). And then, via hidden (first) and experimental (later) supplant all our current functions to use the new stuff instead of the existing one.

          That would allow to set one site like moodle.org (really time-zone intensive) to use that experimental setting, and get any problem in 2.0.x... Then, in 2.1... it would become the "standard" operation mode.

          Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - +1 to create one small tzlib, for all the date/time operations needed (fully tested, asking for all sort of crazy stuff, checking for results via WS somewhere...). And then, via hidden (first) and experimental (later) supplant all our current functions to use the new stuff instead of the existing one. That would allow to set one site like moodle.org (really time-zone intensive) to use that experimental setting, and get any problem in 2.0.x... Then, in 2.1... it would become the "standard" operation mode. Ciao
          Hide
          Petr Škoda added a comment -

          It seems like PHP authors decided to finally address this issue in PHP 5.4 - from the changelog:
          Removed the timezone guessing algorithm in case the timezone isn't set with date.timezone or date_default_timezone_set(). Instead of a guessed timezone, "UTC" is now used instead. (Derick)

          Show
          Petr Škoda added a comment - It seems like PHP authors decided to finally address this issue in PHP 5.4 - from the changelog: Removed the timezone guessing algorithm in case the timezone isn't set with date.timezone or date_default_timezone_set(). Instead of a guessed timezone, "UTC" is now used instead. (Derick)
          Hide
          Jérôme Mouneyrac added a comment -

          I will not be able to work on this issue in the immediate future. In order to create a truer sense of the state of this issue and to allow other developers to have chance to become involved, I am removing myself as the assignee of this issue.
          For more information, see http://docs.moodle.org/dev/Changes_to_issue_assignment

          Show
          Jérôme Mouneyrac added a comment - I will not be able to work on this issue in the immediate future. In order to create a truer sense of the state of this issue and to allow other developers to have chance to become involved, I am removing myself as the assignee of this issue. For more information, see http://docs.moodle.org/dev/Changes_to_issue_assignment

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated: