Moodle
  1. Moodle
  2. MDL-31425

'Available until' date always uses server time zone (prior to 2.2)

    Details

    • Database:
      Any
    • Testing Instructions:
      Hide

      1. Set the Moodle timezone option $CFG->timezone to a timezone which is different from the server timezone. Enable availability if not already done.

      2. Edit an activity and set its end date to e.g. 14 January.

      3. Look at the database table and obtain the Unix time corresponding to this end date.

      4. Convert this to a real time e.g. using www.epochconverter.com

      Verify that this time is the same as 14 January 23:59 in the selected time zone, and not in the server's time zone.

      Known issue: On a DST crossover day the result will be slightly incorrect (by one hour). This is probably preferable to being always incorrect, and possibly by multiple hours, on servers which have a time zone configured.

      Show
      1. Set the Moodle timezone option $CFG->timezone to a timezone which is different from the server timezone. Enable availability if not already done. 2. Edit an activity and set its end date to e.g. 14 January. 3. Look at the database table and obtain the Unix time corresponding to this end date. 4. Convert this to a real time e.g. using www.epochconverter.com Verify that this time is the same as 14 January 23:59 in the selected time zone, and not in the server's time zone. Known issue: On a DST crossover day the result will be slightly incorrect (by one hour). This is probably preferable to being always incorrect, and possibly by multiple hours, on servers which have a time zone configured.
    • Affected Branches:
      MOODLE_21_STABLE
    • Fixed Branches:
      MOODLE_21_STABLE
    • Rank:
      37950

      Description

      When completion tracking is on you have a setting within the assignment called restrict access. You can set for the when assignment will be available until. This setting only allows you to pick a day and not a time.

      When site and user are set to eastern time to assignment becomes restricted at "to 19 January 2012"
      When you have the time zone set to central it says "to 19 January 2012, 10:59 PM"

      When you have the time zone set to mountain time "to 19January 2012, 09:59 PM"

      You would think that the setting would adjust depending on the time zone and not adjust back one hour with the timezone setting.

      This restrict setting overrides the quiz close time so if the teacher is using the restrict time then they would not be able to close the quiz on 11:59 but it would be forced to close on 10:59 no matter if the quiz settings are set to later.

      Tested on
      UTC-6
      UTC-5
      American/Chicago
      America/New_York
      Anerica/Denver

        Issue Links

          Activity

          Hide
          Michael de Raadt added a comment -

          Thanks for reporting that.

          Show
          Michael de Raadt added a comment - Thanks for reporting that.
          Hide
          Sam Marshall added a comment -

          Unless I'm missing something this is intended behaviour. Conditional activity available date/times are supposed to be at a single time worldwide. (Otherwise you could go into your user profile and change your time zone to achieve a few hours' extension on something.)

          So in other words, say you set an activity to be available from 12:00 GMT, then it will become available at 12:00 London time, 04:00 San Francisco time, something like 15:00 in parts of Russia, etc.

          Please reopen if I misunderstood...

          Show
          Sam Marshall added a comment - Unless I'm missing something this is intended behaviour. Conditional activity available date/times are supposed to be at a single time worldwide. (Otherwise you could go into your user profile and change your time zone to achieve a few hours' extension on something.) So in other words, say you set an activity to be available from 12:00 GMT, then it will become available at 12:00 London time, 04:00 San Francisco time, something like 15:00 in parts of Russia, etc. Please reopen if I misunderstood...
          Hide
          Scott Gorsuch added a comment -

          Sam,

          I think perhaps I wasn't clear enough. The Server time is the actual time that the OS is set to. The assignment submission seems to be tied to that, not the time set in Moodle. I do agree that it should not be be modified by user profile but should be tied to the Moodle time, not server/OS time.

          Does this make sense?

          Scott

          Show
          Scott Gorsuch added a comment - Sam, I think perhaps I wasn't clear enough. The Server time is the actual time that the OS is set to. The assignment submission seems to be tied to that, not the time set in Moodle. I do agree that it should not be be modified by user profile but should be tied to the Moodle time, not server/OS time. Does this make sense? Scott
          Hide
          Chris Follin added a comment -

          I don't have permission to reopen this but it does need to be reopened.

          When the Moodle site's timezone and the server's timezone are not the same, as is the case for many of our clients and likely for other partners' clients too, the conditional time is not calculated correctly. It is calculated based on the server time, which for us is always U.S. Eastern time (UTC-5) regardless of where our clients are located. For our clients on the U.S. West Coast (UTC-8), for example, they change their site timezone to U.S. Pacific time but the activities close three hours too soon because they're closing at the end of the day Eastern time.

          The conditional time should be calculated based on the Moodle site timezone setting ($CFG->timezone) and not based on the server's timezone (unless $CFG->timezone=99) or on a user's profile timezone. Only the latter would cause the issue Sam mentioned.

          Show
          Chris Follin added a comment - I don't have permission to reopen this but it does need to be reopened. When the Moodle site's timezone and the server's timezone are not the same, as is the case for many of our clients and likely for other partners' clients too, the conditional time is not calculated correctly. It is calculated based on the server time, which for us is always U.S. Eastern time (UTC-5) regardless of where our clients are located. For our clients on the U.S. West Coast (UTC-8), for example, they change their site timezone to U.S. Pacific time but the activities close three hours too soon because they're closing at the end of the day Eastern time. The conditional time should be calculated based on the Moodle site timezone setting ($CFG->timezone) and not based on the server's timezone (unless $CFG->timezone=99) or on a user's profile timezone. Only the latter would cause the issue Sam mentioned.
          Hide
          Sam Marshall added a comment -

          OK, I've reopened it, but I haven't understood it and can't do anything about fixing it until I do, I'm afraid.

          Let's say we have a case where User A sets the time and User B looks at the website. I think correct behaviour would be:

          • User A sets the time according to their own time zone. For example, let's say they are in Paris (+1). They set the time to 15:00.
          • User B looks at the website and sees the time according to their own time zone. Let's say they have chosen London (+0). They will see the time as 'available until 14:00'.

          It shouldn't matter what the server time zone is and it shouldn't matter what time zone Moodle is set to, except insofar as these might become the default for users. All should be based on the user's time zone as configured in Moodle, and using whatever necessary details.

          (The internal time actually stored in database should of course be UTC in all cases.)

          This behaviour should be the same as in other parts of Moodle. For example, let's say user A adds a course event set to 15:00, then B should see it as 14:00, as above.

          Is this bug stating that the behaviour I just described does not work? This is fully possible, but if so, could you give me an example (since I didn't understand your previous one - apologies).

          Or have I misunderstood the way Moodle is supposed to work?

          Show
          Sam Marshall added a comment - OK, I've reopened it, but I haven't understood it and can't do anything about fixing it until I do, I'm afraid. Let's say we have a case where User A sets the time and User B looks at the website. I think correct behaviour would be: User A sets the time according to their own time zone. For example, let's say they are in Paris (+1). They set the time to 15:00. User B looks at the website and sees the time according to their own time zone. Let's say they have chosen London (+0). They will see the time as 'available until 14:00'. It shouldn't matter what the server time zone is and it shouldn't matter what time zone Moodle is set to, except insofar as these might become the default for users. All should be based on the user's time zone as configured in Moodle, and using whatever necessary details. (The internal time actually stored in database should of course be UTC in all cases.) This behaviour should be the same as in other parts of Moodle. For example, let's say user A adds a course event set to 15:00, then B should see it as 14:00, as above. Is this bug stating that the behaviour I just described does not work? This is fully possible, but if so, could you give me an example (since I didn't understand your previous one - apologies). Or have I misunderstood the way Moodle is supposed to work?
          Hide
          Chris Follin added a comment -

          Hi Sam,

          The user's profile time setting is not the issue. It doesn't matter what any user has chosen for their own timezone.

          The issue is this:

          • The server (the physical computer that runs Moodle) is in UTC-5 timezone. Its operating system time is set to UTC-5. Current "Server Time" is 15:00.
          • The client is a school in California (UTC-8). They are three hours behind us. They set their $CFG->timezone setting to UTC-8 because they want Moodle to operate in their local time rather than our server time. As far as Moodle is concerned in most places of the code, the current time ("Moodle Time") is 12:00 because it adjusts times based on $CFG->timezone.
          • The instructor creates an activity that closes at the end of the day today (there is no other way to set it, it's just at the end of whatever day specified). Again, Moodle time is currently 12:00. That means students should have 12 hours left in the day to complete the activity regardless of their individual profile timezone setting. If the student is in the same timezone as the school (UTC-8), the activity should close at 00:00 their local time. If the student is in U.S. Central Time (UTC-6), their current time is 14:00 and the activity will close at their local time of 02:00 the next morning (00:00 Moodle time in UTC-8 plus two hour timezone difference), but they still have 12 hours remaining. If the student is in Paris (UTC+1), their current local time is 21:00 and the activity will close at their local time of 09:00 the next morning (00:00 Moodle time in UTC-8 plus nine hour timezone difference), but they also still have 12 hours remaining.
          • What is actually happening is that the activity isn't closing at 00:00 Moodle Time (UTC-8). It is closing at 00:00 Server Time (UTC-5), which is only 21:00 "Moodle Time." In other words, it's closing three hours early. For the student local to the school, they really only have nine hours instead of 12 because it will close at 21:00. For the student in Central Time (UTC-6), it will close at their local time of 23:00 (when it is 00:00 "Server Time") instead of 02:00 (when it is 00:00 "Moodle Time"). For the student in Paris (UTC+1), it will close at their local time of 06:00 (when it is 00:00 "Server Time") instead of 09:00 (when it is 00:00 "Moodle Time"). In all cases, students are equal in having nine hours remaining, but they shouldn't have nine; they should have 12 hours remaining.

          I suspect the code may be using PHP's date() function instead of Moodle date functions that can account for $CFG->timezone. I have not looked into this specific code but we have found other cases of date() being used and causing issues similar to this.

          I hope that this clears up the confusion.

          Show
          Chris Follin added a comment - Hi Sam, The user's profile time setting is not the issue. It doesn't matter what any user has chosen for their own timezone. The issue is this: The server (the physical computer that runs Moodle) is in UTC-5 timezone. Its operating system time is set to UTC-5. Current "Server Time" is 15:00. The client is a school in California (UTC-8). They are three hours behind us. They set their $CFG->timezone setting to UTC-8 because they want Moodle to operate in their local time rather than our server time. As far as Moodle is concerned in most places of the code, the current time ("Moodle Time") is 12:00 because it adjusts times based on $CFG->timezone. The instructor creates an activity that closes at the end of the day today (there is no other way to set it, it's just at the end of whatever day specified). Again, Moodle time is currently 12:00. That means students should have 12 hours left in the day to complete the activity regardless of their individual profile timezone setting. If the student is in the same timezone as the school (UTC-8), the activity should close at 00:00 their local time. If the student is in U.S. Central Time (UTC-6), their current time is 14:00 and the activity will close at their local time of 02:00 the next morning (00:00 Moodle time in UTC-8 plus two hour timezone difference), but they still have 12 hours remaining. If the student is in Paris (UTC+1), their current local time is 21:00 and the activity will close at their local time of 09:00 the next morning (00:00 Moodle time in UTC-8 plus nine hour timezone difference), but they also still have 12 hours remaining. What is actually happening is that the activity isn't closing at 00:00 Moodle Time (UTC-8). It is closing at 00:00 Server Time (UTC-5), which is only 21:00 "Moodle Time." In other words, it's closing three hours early. For the student local to the school, they really only have nine hours instead of 12 because it will close at 21:00. For the student in Central Time (UTC-6), it will close at their local time of 23:00 (when it is 00:00 "Server Time") instead of 02:00 (when it is 00:00 "Moodle Time"). For the student in Paris (UTC+1), it will close at their local time of 06:00 (when it is 00:00 "Server Time") instead of 09:00 (when it is 00:00 "Moodle Time"). In all cases, students are equal in having nine hours remaining, but they shouldn't have nine; they should have 12 hours remaining. I suspect the code may be using PHP's date() function instead of Moodle date functions that can account for $CFG->timezone. I have not looked into this specific code but we have found other cases of date() being used and causing issues similar to this. I hope that this clears up the confusion.
          Hide
          Sam Marshall added a comment -

          Argh! Sorry, I completely understand now.

          You're using the old (2.1) version where it didn't support time, only date. Basically the way this worked was incoherent by definition, and you're right, if multiple timezones are involved it would probably completely fall over. Surely it also had the bug you mentioned about using server time zone instead of Moodle time zone.

          In 2.2 we fixed it using work by the community (and me). This is MDL-27242. Now it uses both a date and time.

          Using qa.moodle.net I tested the following scenario:

          a) The server is probably set to Australian time.
          b) I changed the server admin settings so the default timezone is London.
          c) I set up the manager account to use Paris timezone.

          Using the manager account, I then set a conditional activity to be available until 12:30. As that user's timezone is set to Paris, it should be available until 11:30 my time (I'm in London timezone).

          If this incorrectly used the Australian timezone then it would already have been closed; if this incorrectly used the London timezone it would not close for another hour.

          I then logged in using student account (at 11:28 or so my time) and verified that the activity was available. I waited until 11:31 and tried again - now it had gone.

          So I think this is working now. It is certainly broken in 2.1, but I don't think it's really feasible to fix it there unless we backport the whole feature.

          I'm going to mark this as duplicate of the other issue but will leave it open (& change versions to clarify that it only applies to 2.1) in case anyone has time to do and test a fix on the 2.1 code, or HQ decides to backport the feature from 2.2 which might be easiest. I'm not personally going to do anything about it though, sorry.

          Show
          Sam Marshall added a comment - Argh! Sorry, I completely understand now. You're using the old (2.1) version where it didn't support time, only date. Basically the way this worked was incoherent by definition, and you're right, if multiple timezones are involved it would probably completely fall over. Surely it also had the bug you mentioned about using server time zone instead of Moodle time zone. In 2.2 we fixed it using work by the community (and me). This is MDL-27242 . Now it uses both a date and time. Using qa.moodle.net I tested the following scenario: a) The server is probably set to Australian time. b) I changed the server admin settings so the default timezone is London. c) I set up the manager account to use Paris timezone. Using the manager account, I then set a conditional activity to be available until 12:30. As that user's timezone is set to Paris, it should be available until 11:30 my time (I'm in London timezone). If this incorrectly used the Australian timezone then it would already have been closed; if this incorrectly used the London timezone it would not close for another hour. I then logged in using student account (at 11:28 or so my time) and verified that the activity was available. I waited until 11:31 and tried again - now it had gone. So I think this is working now. It is certainly broken in 2.1, but I don't think it's really feasible to fix it there unless we backport the whole feature. I'm going to mark this as duplicate of the other issue but will leave it open (& change versions to clarify that it only applies to 2.1) in case anyone has time to do and test a fix on the 2.1 code, or HQ decides to backport the feature from 2.2 which might be easiest. I'm not personally going to do anything about it though, sorry.
          Hide
          Chris Follin added a comment -

          Sam,

          I don't think backporting the entire feature from 2.2 is necessary but there is a bug here that should be fixed in 2.1.

          I looked into both the database and the code to see exactly what is going on. The availablefrom date in mdl_course_modules was set to a UNIX timestamp representing the correct midnight time in the $CFG->timezone zone. But the availableuntil date in the same table was set to a UNIX timestamp representing midnight in the server's timezone, which is incorrect. The problem is occurring when the course module is created or updated and saved into the database.

          Looking further, the culprit is the use of strtotime(). From course/modedit.php:

          // The form time is midnight, but because we want it to be
          // inclusive, set it to 23:59:59 on that day.
          if ($cm->availableuntil) {
              $cm->availableuntil = strtotime('23:59:59',
                  $cm->availableuntil);
          }
          

          That calculates one second before midnight in the server's (PHP's) timezone, not Moodle's timezone ($CFG->timezone).

          $cm->availableuntil and $cm->availablefrom come from the form as timestamps already representing midnight in the desired timezone. I couldn't find a Moodle function that looked appropriate for the situation without needing to do extra processing. $cm->availableuntil will always be midnight on a given date because the user can't select anything else in 2.1, so I'm proposing a simple solution of adding 86,399 seconds (23:59:59) to $cm->availableuntil rather than using strtotime().

          // The form time is midnight, but because we want it to be
          // inclusive, add 23:59:59 to the time (86,399 seconds).
          if ($cm->availableuntil) {
              $cm->availableuntil += 86399;
          }
          

          I tested this and the availableuntil date is now saved as a time stamp representing 23:59:59 in Moodle's timezone rather than in the server's timezone. Then the activity closes at the correct local time of wherever the student is located. In Los Angeles it would close at 23:59:59. In New York it would close at 02:59:59. In London it would close at 07:59:59.

          I'm attaching a patch of the above modification.

          Show
          Chris Follin added a comment - Sam, I don't think backporting the entire feature from 2.2 is necessary but there is a bug here that should be fixed in 2.1. I looked into both the database and the code to see exactly what is going on. The availablefrom date in mdl_course_modules was set to a UNIX timestamp representing the correct midnight time in the $CFG->timezone zone. But the availableuntil date in the same table was set to a UNIX timestamp representing midnight in the server's timezone, which is incorrect. The problem is occurring when the course module is created or updated and saved into the database. Looking further, the culprit is the use of strtotime(). From course/modedit.php: // The form time is midnight, but because we want it to be // inclusive, set it to 23:59:59 on that day. if ($cm->availableuntil) { $cm->availableuntil = strtotime('23:59:59', $cm->availableuntil); } That calculates one second before midnight in the server's (PHP's) timezone, not Moodle's timezone ($CFG->timezone). $cm->availableuntil and $cm->availablefrom come from the form as timestamps already representing midnight in the desired timezone. I couldn't find a Moodle function that looked appropriate for the situation without needing to do extra processing. $cm->availableuntil will always be midnight on a given date because the user can't select anything else in 2.1, so I'm proposing a simple solution of adding 86,399 seconds (23:59:59) to $cm->availableuntil rather than using strtotime(). // The form time is midnight, but because we want it to be // inclusive, add 23:59:59 to the time (86,399 seconds). if ($cm->availableuntil) { $cm->availableuntil += 86399; } I tested this and the availableuntil date is now saved as a time stamp representing 23:59:59 in Moodle's timezone rather than in the server's timezone. Then the activity closes at the correct local time of wherever the student is located. In Los Angeles it would close at 23:59:59. In New York it would close at 02:59:59. In London it would close at 07:59:59. I'm attaching a patch of the above modification.
          Hide
          Sam Marshall added a comment -

          Thanks, patch looks good, I'll submit for review.

          I note there will be a bug if you set the time on a DST switchover day (either one) which is probably why it used strtotime originally, but that bug is less bad than this one, so submitting it anyhow.

          Show
          Sam Marshall added a comment - Thanks, patch looks good, I'll submit for review. I note there will be a bug if you set the time on a DST switchover day (either one) which is probably why it used strtotime originally, but that bug is less bad than this one, so submitting it anyhow.
          Hide
          Jason Fowler added a comment -

          Code looks good, and the logic seems to solve the issue

          Show
          Jason Fowler added a comment - Code looks good, and the logic seems to solve the issue
          Hide
          Sam Marshall added a comment -

          Thanks for review - submitting for integration.

          Show
          Sam Marshall added a comment - Thanks for review - submitting for integration.
          Hide
          Aparup Banerjee added a comment -

          Thanks, thats been integrated into 21 only.

          Show
          Aparup Banerjee added a comment - Thanks, thats been integrated into 21 only.
          Hide
          Adrian Greeve added a comment -

          After reading the description and other details that other people posted in an effort to understand what I am testing, I ran through the instructions and the timeclose unix time does correspond with the time set in Moodle.

          Show
          Adrian Greeve added a comment - After reading the description and other details that other people posted in an effort to understand what I am testing, I ran through the instructions and the timeclose unix time does correspond with the time set in Moodle.
          Hide
          Eloy Lafuente (stronk7) added a comment -

          A bit later this week, but finally your changes have been accepted and are now available in all the upstream git/cvs servers.

          Many thanks & ciao

          Show
          Eloy Lafuente (stronk7) added a comment - A bit later this week, but finally your changes have been accepted and are now available in all the upstream git/cvs servers. Many thanks & ciao

            People

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

              Dates

              • Created:
                Updated:
                Resolved: