Uploaded image for project: '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
    • Status: Closed
    • Priority: Minor
    • Resolution: Inactive
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Component/s: Libraries
    • Labels:
    • Affected Branches:
      MOODLE_20_STABLE

      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.

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            dougiamas 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
            dougiamas 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
            dougiamas Martin Dougiamas added a comment -

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

            Show
            dougiamas Martin Dougiamas added a comment - I committed this to lib/setup.php to avoid the warnings.
            Hide
            jtomkinson 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
            jtomkinson 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
            mudrd8mz 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
            mudrd8mz 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
            stronk7 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
            stronk7 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
            jtomkinson Jordan Tomkinson added a comment -

            bump for justice

            Show
            jtomkinson Jordan Tomkinson added a comment - bump for justice
            Hide
            stronk7 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
            stronk7 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
            dougiamas 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
            dougiamas 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
            stronk7 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
            stronk7 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
            skodak Petr Skoda 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
            skodak Petr Skoda 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
            jerome 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
            jerome 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
            Hide
            tgus Tim Gus added a comment -

            I've updated the description of the "Default timezone" setting in MDL-45617 which informs users to select PHP compatible timezones.

            Show
            tgus Tim Gus added a comment - I've updated the description of the "Default timezone" setting in MDL-45617 which informs users to select PHP compatible timezones.
            Hide
            poltawski Dan Poltawski added a comment -

            Closing this issue - I think its been addressed by various changes over the years - and more completely in MDL-49684

            Show
            poltawski Dan Poltawski added a comment - Closing this issue - I think its been addressed by various changes over the years - and more completely in MDL-49684

              People

              • Votes:
                1 Vote for this issue
                Watchers:
                11 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: