Add-ons
  1. Add-ons
  2. CONTRIB-3555

Changes in timezone throw off scheduled appointments by one hour

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 2.1
    • Fix Version/s: None
    • Component/s: Module: Scheduler
    • Labels:
      None
    • Affected Branches:
      MOODLE_21_STABLE
    • Rank:
      38993

      Description

      A Scheduler appointment made in a timezone (e.g. GMT) for a future point after a change in timezone (e.g. the UK's recent change to BST) result in schedules being off by one hour.

      Example: On the first of March, I make an appointment slot for the first of April at 9am, for one hour. On the 25th March in the UK, clocks are put forward one hour (changing from GMT to BST). From this point onward, the scheduled appointment looks like it has been made for 10am, not 9am.

        Issue Links

          Activity

          Paul Vaughan created issue -
          Paul Vaughan made changes -
          Field Original Value New Value
          Link This issue will be resolved by MDL-17672 [ MDL-17672 ]
          Paul Vaughan made changes -
          Link This issue will be resolved by MDL-26391 [ MDL-26391 ]
          Henning Bostelmann made changes -
          Assignee Valery Fremaux [ vf ] Henning Bostelmann [ bostelm ]
          Hide
          Henning Bostelmann added a comment -

          Hello Paul,

          This problem is a little hard to reproduce, and in the code I see no obvious reason for the error, so let me ask what precisely was happening.

          Did you actually go through the procedure above (as described in "Example")? If yes, what was the "time zone" in the user profile set to? Was this user a teacher or a student?

          Or, on the other hand, did you see the change when manually changing the user profile field for "time zone"?

          Best wishes
          Henning

          Show
          Henning Bostelmann added a comment - Hello Paul, This problem is a little hard to reproduce, and in the code I see no obvious reason for the error, so let me ask what precisely was happening. Did you actually go through the procedure above (as described in "Example")? If yes, what was the "time zone" in the user profile set to? Was this user a teacher or a student? Or, on the other hand, did you see the change when manually changing the user profile field for "time zone"? Best wishes Henning
          Hide
          Paul Vaughan added a comment -

          Hi Henning.

          Yes, I've absolutely been through the procedure above, but the user's timezone wasn't changed manually: Our users are defaulted to 'server timezone' and also not permitted to change it, so the error happens when the server automatically updates it's time from GMT to BST. (FWIW, we're running Debian 6.0.3/Squeeze.)

          I hope this is of use to you. Please let me know if I can provide further info/testing.

          Paul.

          Show
          Paul Vaughan added a comment - Hi Henning. Yes, I've absolutely been through the procedure above, but the user's timezone wasn't changed manually: Our users are defaulted to 'server timezone' and also not permitted to change it, so the error happens when the server automatically updates it's time from GMT to BST. (FWIW, we're running Debian 6.0.3/Squeeze.) I hope this is of use to you. Please let me know if I can provide further info/testing. Paul.
          Hide
          Henning Bostelmann added a comment -

          Hi Paul,

          sorry to bother you again. Can you tell me what your configuration settings for "timezone" and "forcetimezone" are (as found in "Location Settings")? For comparison, on our system we use

          timezone: "Server's local time"
          forcetimezone: "Europe/London"

          and the problem doesn't seem to occur, at least no user has reported it yet.

          Henning

          Show
          Henning Bostelmann added a comment - Hi Paul, sorry to bother you again. Can you tell me what your configuration settings for "timezone" and "forcetimezone" are (as found in "Location Settings")? For comparison, on our system we use timezone: "Server's local time" forcetimezone: "Europe/London" and the problem doesn't seem to occur, at least no user has reported it yet. Henning
          Hide
          Paul Vaughan added a comment -

          No bother at all. Our settings are as follows:

          Timezone: 'Server's local time'
          Force default timezone: 'Users can choose their own timezone.'

          I had thought it was set to 'force', but a quick scan of the database shows that everyone is using timezone 99.

          Show
          Paul Vaughan added a comment - No bother at all. Our settings are as follows: Timezone: 'Server's local time' Force default timezone: 'Users can choose their own timezone.' I had thought it was set to 'force', but a quick scan of the database shows that everyone is using timezone 99.
          Hide
          Henning Bostelmann added a comment -

          OK, that may explain the problem. I expect that if you set "force default timezone" to "Europe/London", the problem will be fixed.

          What happens seems to be the following: On the 1st March, the server's timezone is GMT. When you make an appointment on 1st March for 1st April, 9am, then the appointment time is stored as "April 1, 9:00 GMT". (All times in the database are stored as Unix timestamps, which always refer to GMT.) Later, the timezone changes (on the server) to BST. Now "April 1, 9:00 GMT" is (correctly!) displayed as "April 1, 10:00 BST".

          This is avoided by not using "Server's default time zone" but rather "Europe/London". Moodle will then take into account, at the time of data entry, that "April 1, 9:00 Europe/London" means "April 1, 9:00 BST" and hence "April 1, 8:00 GMT", and will store the time as such.

          As far as I can see, this is a quirk in Moodle core, not directly in Scheduler. Likely, Moodle calendar events behave the same way.

          Show
          Henning Bostelmann added a comment - OK, that may explain the problem. I expect that if you set "force default timezone" to "Europe/London", the problem will be fixed. What happens seems to be the following: On the 1st March, the server's timezone is GMT. When you make an appointment on 1st March for 1st April, 9am, then the appointment time is stored as "April 1, 9:00 GMT". (All times in the database are stored as Unix timestamps, which always refer to GMT.) Later, the timezone changes (on the server) to BST. Now "April 1, 9:00 GMT" is (correctly!) displayed as "April 1, 10:00 BST". This is avoided by not using "Server's default time zone" but rather "Europe/London". Moodle will then take into account, at the time of data entry, that "April 1, 9:00 Europe/London" means "April 1, 9:00 BST" and hence "April 1, 8:00 GMT", and will store the time as such. As far as I can see, this is a quirk in Moodle core, not directly in Scheduler. Likely, Moodle calendar events behave the same way.
          Hide
          Amanda Doughty added a comment -

          We had this issue and I fixed it for 1.9. Any slots set beyond either the October or March BST/GMT change, displayed ok until after those dates and then they all went back/forward an hour. It was because the 1.9 scheduler did not use the Moodle date selector.

          The only way to recreate it is to use a local Moodle installation, create some slots say in November 2012 and then change your PC date to a day in November.

          I have not tested it in 2.2 yet, so this may be irrelevant.

          Show
          Amanda Doughty added a comment - We had this issue and I fixed it for 1.9. Any slots set beyond either the October or March BST/GMT change, displayed ok until after those dates and then they all went back/forward an hour. It was because the 1.9 scheduler did not use the Moodle date selector. The only way to recreate it is to use a local Moodle installation, create some slots say in November 2012 and then change your PC date to a day in November. I have not tested it in 2.2 yet, so this may be irrelevant.
          Hide
          Henning Bostelmann added a comment -

          Another timezone-related issue.

          Show
          Henning Bostelmann added a comment - Another timezone-related issue.
          Henning Bostelmann made changes -
          Link This issue has a non-specific relationship to CONTRIB-3912 [ CONTRIB-3912 ]
          Hide
          anis jradah added a comment -

          Dear All,

          Any updates concerning a fix for this problem, we are using 2.4.5

          Regards,
          Anis

          Show
          anis jradah added a comment - Dear All, Any updates concerning a fix for this problem, we are using 2.4.5 Regards, Anis
          Hide
          Henning Bostelmann added a comment -

          Anis, are you using the "server default" setting in your Moodle timezone settings? If yes, then you're affected by a Moodle Core bug (not Scheduler); for updates see MDL-26391. If not, let me know which exact problem you're seeing.

          Show
          Henning Bostelmann added a comment - Anis, are you using the "server default" setting in your Moodle timezone settings? If yes, then you're affected by a Moodle Core bug (not Scheduler); for updates see MDL-26391 . If not, let me know which exact problem you're seeing.
          Hide
          Anis Jradah added a comment -

          Dear Henning,

          Sorry for the late reply.

          We are not using the "Server default" but UTC+2 in "Default timezone".
          We once used the Asia/Beirut and it gave a wrong timing.

          So we manually change the timezone to UTC+3. But lots of complains we receive that the time of an event has changed; and instructor change manually the time of the event/quiz/forum, etc...

          Moreover, Force default timezone for user is set to "Users can choose their own timezone".

          Thank you for your help.

          Show
          Anis Jradah added a comment - Dear Henning, Sorry for the late reply. We are not using the "Server default" but UTC+2 in "Default timezone". We once used the Asia/Beirut and it gave a wrong timing. So we manually change the timezone to UTC+3. But lots of complains we receive that the time of an event has changed; and instructor change manually the time of the event/quiz/forum, etc... Moreover, Force default timezone for user is set to "Users can choose their own timezone". Thank you for your help.
          Hide
          Henning Bostelmann added a comment -

          Hi Anis, thanks for these details.

          Yes, that seems understandable. All dates and times within Moodle (whether in a quiz, calendar event, scheduler, or otherwise) are internally stored in UTC. They are converted to the user's timezone every time that someone views the corresponding page in Moodle. Therefore, when users change their timezone - or when you change it for them - all times of events etc. will change from the user's point of view.

          One can debate whether that's an intended behaviour or rather a bug (in your case, you clearly didn't intend it to behave like that). However, it's nothing that I can fix in Scheduler. It's to do with the way that Moodle core handles times and time zones.

          Show
          Henning Bostelmann added a comment - Hi Anis, thanks for these details. Yes, that seems understandable. All dates and times within Moodle (whether in a quiz, calendar event, scheduler, or otherwise) are internally stored in UTC. They are converted to the user's timezone every time that someone views the corresponding page in Moodle. Therefore, when users change their timezone - or when you change it for them - all times of events etc. will change from the user's point of view. One can debate whether that's an intended behaviour or rather a bug (in your case, you clearly didn't intend it to behave like that). However, it's nothing that I can fix in Scheduler. It's to do with the way that Moodle core handles times and time zones.

            People

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

              Dates

              • Created:
                Updated:

                Development