Moodle
  1. Moodle
  2. MDL-26391

Remove 'Server default' option in the Moodle settings

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Blocker Blocker
    • Resolution: Unresolved
    • Affects Version/s: 1.9.10, 2.0.1, 2.1.5
    • Fix Version/s: None
    • Component/s: Libraries
    • Labels:
    • Affected Branches:
      MOODLE_19_STABLE, MOODLE_20_STABLE, MOODLE_21_STABLE
    • Rank:
      15982

      Description

      'Server default' should be removed from the time zone options.

      'UTC' will be the default option in the Moodle administration.
      'Site timezone' will be the default option in the user profil.

      Write a upgrade script that fix Moodle/Users timzone set to 'server default'. At the end of the upgrade script display the timezone settings, so the Moodle administrator can change it. The upgrade script should try to detect the right admin user timezone. (most of the time an admin will prefer to set a site to his/her own timezone than were the server is hosted.)

        Issue Links

          Activity

          Hide
          Petr Škoda added a comment -

          I am afraid we can not change the date routines in the middle of stable - many ppl rely on known problem workarounds, even some code relies on our current code weirdness.

          Please consider this change only for 2.1 once we rewrite the date/calendar handling routines and test it properly on all systems and for all time zones.

          Show
          Petr Škoda added a comment - I am afraid we can not change the date routines in the middle of stable - many ppl rely on known problem workarounds, even some code relies on our current code weirdness. Please consider this change only for 2.1 once we rewrite the date/calendar handling routines and test it properly on all systems and for all time zones.
          Hide
          Martin Dougiamas added a comment -

          I think the question here is not about changing date calculations but more about forcing the admin to choose an explicit timezone, since we know the auto-server-setting part is buggy already. So my +10 for 2.0.x

          Show
          Martin Dougiamas added a comment - I think the question here is not about changing date calculations but more about forcing the admin to choose an explicit timezone, since we know the auto-server-setting part is buggy already. So my +10 for 2.0.x
          Hide
          Petr Škoda added a comment -

          You can not "force" admin now - it may be buggy but those bugs are known for several years. My +10 to keep this option available and unchanged.

          Show
          Petr Škoda added a comment - You can not "force" admin now - it may be buggy but those bugs are known for several years. My +10 to keep this option available and unchanged.
          Hide
          Tim Hunt added a comment -

          What about adding one of those nagging messages to admin notifications, like the insecure dataroot one, when the site timezone has not been set properly?

          Show
          Tim Hunt added a comment - What about adding one of those nagging messages to admin notifications, like the insecure dataroot one, when the site timezone has not been set properly?
          Hide
          Petr Škoda added a comment -

          Tim: I think that is a good idea.

          Show
          Petr Škoda added a comment - Tim: I think that is a good idea.
          Hide
          Jérôme Mouneyrac added a comment -
          Show
          Jérôme Mouneyrac added a comment - I did a quick patch following Tim suggest: https://github.com/mouneyrac/moodle/commit/0c3cdd914b501fd7ebc3c555fa55633d263a043b
          Hide
          Petr Škoda added a comment -

          My personal experience is the opposite, if you have all users in the same timezone and DST it seems best to keep the setting to 'Server default' due to known DST problems in the calendar.

          Show
          Petr Škoda added a comment - My personal experience is the opposite, if you have all users in the same timezone and DST it seems best to keep the setting to 'Server default' due to known DST problems in the calendar.
          Hide
          Jérôme Mouneyrac added a comment -

          List of all DST issue on Jira search:
          (summary ~ dst OR description ~ dst OR comment ~ dst) AND status in (Open, "In Progress", Reopened) ORDER BY updated DESC

          Show
          Jérôme Mouneyrac added a comment - List of all DST issue on Jira search: (summary ~ dst OR description ~ dst OR comment ~ dst) AND status in (Open, "In Progress", Reopened) ORDER BY updated DESC
          Hide
          Martin Dougiamas added a comment -

          Petr I'd really like to see that bug reported with details if you have them ...

          Show
          Martin Dougiamas added a comment - Petr I'd really like to see that bug reported with details if you have them ...
          Hide
          Petr Škoda added a comment -

          I was dealing with this 3 years ago, there were discussions and tracker issues, but I do not remember the details because I decided to solve it with the "Default server" option which works fine without any complains.

          Issues were:
          1/ when DST changes the calendar events that were created in advance move by 1 h
          2/ repeated events are repeated in the original DST/TZ

          Show
          Petr Škoda added a comment - I was dealing with this 3 years ago, there were discussions and tracker issues, but I do not remember the details because I decided to solve it with the "Default server" option which works fine without any complains. Issues were: 1/ when DST changes the calendar events that were created in advance move by 1 h 2/ repeated events are repeated in the original DST/TZ
          Hide
          Martin Dougiamas added a comment -

          Eloy mentioned he'd done a lot of work on timezones about 2 years ago, probably these were fixed.

          Show
          Martin Dougiamas added a comment - Eloy mentioned he'd done a lot of work on timezones about 2 years ago, probably these were fixed.
          Hide
          Petr Škoda added a comment -

          Definitely not fixed for me, please do not change things like this in the middle of stable branch. If the "Default server" ever gets removed the upgrade is going to be a real pain...

          Show
          Petr Škoda added a comment - Definitely not fixed for me, please do not change things like this in the middle of stable branch. If the "Default server" ever gets removed the upgrade is going to be a real pain...
          Hide
          Henning Bostelmann added a comment - - edited

          Doesn't seem fixed for me. Users reported similar problems in the Scheduler module (CONTRIB-3555): Local times entered outside DST suddenly appear shifted when DST comes into effect. But Scheduler just uses the core lib functionality at this point; I expect that the same problems would occur in the core Moodle calendar as well.

          A workaround is not to use "Server's local time", or to use the "Force Timezone" setting. While the "Server's local time" option is not removed, users should be strongly advised not to use this setting.

          Show
          Henning Bostelmann added a comment - - edited Doesn't seem fixed for me. Users reported similar problems in the Scheduler module ( CONTRIB-3555 ): Local times entered outside DST suddenly appear shifted when DST comes into effect. But Scheduler just uses the core lib functionality at this point; I expect that the same problems would occur in the core Moodle calendar as well. A workaround is not to use "Server's local time", or to use the "Force Timezone" setting. While the "Server's local time" option is not removed, users should be strongly advised not to use this setting.
          Hide
          Michael de Raadt added a comment -

          Is this really a blocker? I'm not sure that's really relatively correct for this issue and I can't see when it became a blocker.

          Show
          Michael de Raadt added a comment - Is this really a blocker? I'm not sure that's really relatively correct for this issue and I can't see when it became a blocker.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          I think we only can reconsider this (and a lot of related issues) when both these are achieved:

          1) Move from Moodle TZs to PHP TZs (better performance, way more accurate...).
          2) Add TZ to events (else repetitions won't work ever properly).

          I bet that with the 2 above done, 99% of TZ/DST zones will disappear. Till then I'd halt any drastic change like this.

          My 2 cents. Ciao

          Show
          Eloy Lafuente (stronk7) added a comment - I think we only can reconsider this (and a lot of related issues) when both these are achieved: 1) Move from Moodle TZs to PHP TZs (better performance, way more accurate...). 2) Add TZ to events (else repetitions won't work ever properly). I bet that with the 2 above done, 99% of TZ/DST zones will disappear. Till then I'd halt any drastic change like this. My 2 cents. Ciao
          Hide
          Petr Škoda added a comment -

          It is not just repetition, timestamp is not enough for all future events, we need to recalculate when DST definition changes.

          Show
          Petr Škoda added a comment - It is not just repetition, timestamp is not enough for all future events, we need to recalculate when DST definition changes.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          Petr, I just named repetitions coz it's the most obvious place where events are failing badly for everybody. But yes, the 2) above is about to add TZ to all events.

          Show
          Eloy Lafuente (stronk7) added a comment - Petr, I just named repetitions coz it's the most obvious place where events are failing badly for everybody. But yes, the 2) above is about to add TZ to all events.
          Hide
          Petr Škoda added a comment -

          My point was we do not need it for past/current events. That is in logs is timestamp fine, for timecreated/modified fields too, BUT for calendar and some enrolment dates for example we need the timezone+original and timestamp.

          Show
          Petr Škoda added a comment - My point was we do not need it for past/current events. That is in logs is timestamp fine, for timecreated/modified fields too, BUT for calendar and some enrolment dates for example we need the timezone+original and timestamp.
          Hide
          Mike Wilday added a comment -

          Any other work being done on this issue? We are still majorly affected by this in the Americas/Los Angeles time zone. And is still affecting Moodle 2.4.

          Show
          Mike Wilday added a comment - Any other work being done on this issue? We are still majorly affected by this in the Americas/Los Angeles time zone. And is still affecting Moodle 2.4.

            People

            • Votes:
              5 Vote for this issue
              Watchers:
              15 Start watching this issue

              Dates

              • Created:
                Updated: