Moodle
  1. Moodle
  2. MDL-26391

Remove 'Server default' option in the Moodle settings

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Duplicate
    • 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

      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.)

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            Petr Skoda 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 Skoda 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 Skoda 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 Skoda 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 Skoda added a comment -

            Tim: I think that is a good idea.

            Show
            Petr Skoda 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 Skoda 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 Skoda 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 Skoda 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 Skoda 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 Skoda 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 Skoda 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 Skoda 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 Skoda 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 Skoda 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 Skoda 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.
            Hide
            Dan Poltawski added a comment -

            Closing this as a duplicate of MDL-49684 which addresses this

            Show
            Dan Poltawski added a comment - Closing this as a duplicate of MDL-49684 which addresses this

              People

              • Votes:
                6 Vote for this issue
                Watchers:
                17 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: