[SAK-36858] Available/Due dates change to match Time Zone offset when test settings are saved Created: 04-Jan-2017  Updated: 24-Sep-2018  Resolved: 17-Feb-2017

Status: Verified
Project: Sakai
Component/s: Tests & Quizzes (Samigo)
Affects Version/s: 11.2
Fix Version/s: 11.5 [Tentative], 12.0

Type: Bug Priority: Blocker
Reporter: Molly Kelsey (Inactive) Assignee: SAMIGO TEAM (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

https://trunk-mysql.nightly.sakaiproject.org/portal/


Attachments: PNG File Settings.png     PNG File setttings2.png    
Issue Links:
Incorporate
is incorporated by SAK-34309 Parent Jira for testing on Master for... OPEN
Relate
is related to SAK-40226 samigo: If user time zone differs fro... In Progress
is related to SAK-40678 Samigo start, end, etc. dates change ... CLOSED
11 status: Resolved
Previous Issue Keys: SAM-3106

 Description   

If a test is created on a computer in a different time zone than the server, the Available/Due dates are changed to match the time zone of the server when the test is saved.

If the server is on EST, when a test is created from a PST computer to be due at 9:00am, clicking Save changes that time to 12:00p. After this, every time the Settings are edited, the main test time is increased by the time zone change again (to 3:00p, then 6:00p, etc.) and the exceptions settings are changed to 24hr time (1300 vs 1:00p)

To replicate:

  1. Change computer time zone so that the system clock does not match the server time
  2. Create an assessment, go to Settings
  3. Add Available/Due dates
  4. Create an Exception
  5. Click Add a Time Limit/Delivery Date Exception
  6. Click Save Settings and Publish - note time shown
  7. Click Edit Settings
  8. Click Save Settings and Publish again - note the time shown is increased by the time change again (i.e. if 1hr was added originally, 2 are added now)


 Comments   
Comment by Neal Caidin [ 04-Jan-2017 ]

I think we may have to make this a blocker for 11.3 ?

I tested against 10 and could not reproduce the problem. But against 11.x I can.

Many schools have distance programs and other use cases in which the instructor is in a different time zone.

Comment by Sam Ottenhoff [ 05-Jan-2017 ]

Is this any different from SAM-2662 ?

Comment by Neal Caidin [ 05-Jan-2017 ]

Interesting. It does seem similar to SAM-2662 . I don't know if that means we should not have closed SAM-2662 or if it means this is a feature request and not a bug. In this moment to me it seems like the way it behaves is very bad and confusing because if you are an instructor operating in a different timezone than where your institution , which seems like it is probably happening more and more, then each time you edit your settings, even if you don't touch the date/time fields, they get updated. That seems like a bad surprise.

Comment by Neal Caidin [ 10-Jan-2017 ]

Need to test with Sakai Preference for Time Zone with this behavior.

Comment by Neal Caidin [ 12-Jan-2017 ]

Setting the Timezone preference in Sakai to match the timezone setting of one's local (date/time specified in your PC's settings) seems to resolve this issue. I'm inclined to close this one as a "non-issue".

Comment by Sam Ottenhoff [ 12-Feb-2017 ]

I am re-opening. I think this is legit issue and the steps to replicate here are excellent.

Comment by Sam Ottenhoff [ 12-Feb-2017 ]

So how should we deal with the following scenario: institution is in Central timezone. Sakai is in Central timezone. Professor is remote and is in Eastern timezone. Professor sets a due date for "1pm tomorrow". What time is the due date?

I would argue that the expectation is that the due date is 1pm Central time as that is where the system is based. What do others think?

Comment by Shawn Foster [ 13-Feb-2017 ]

Good point, Sam.

How does it work now for other tools? What time are all release and due dates across tools? Are times set to the system's time or to the user's time? Are they consistent? If I recall correctly, I think I've seen inconsistencies while testing other time zones. This would be another case that needs tool standardization from the project we discussed at SakaiCamp 2017.

Do we show the time zones in any tools currently? If not, I think we should add time zones to all times in Sakai. We could start with Samigo to help address this case.

Comment by Sam Ottenhoff [ 13-Feb-2017 ]

I believe the majority of tools simply use server time.

For users operating in the non-server timezone, the addition of the timezone will be very helpful. For the vast majority of institutions in the world, this probably isn't a great concern.

Comment by Shawn Foster [ 13-Feb-2017 ]

As distance learning (and remote teaching) continues to increase, having the time zone visible with every date should be as necessary as indicating whether the time is morning or night ("a.m." or "p.m."), right?

Comment by Sam Ottenhoff [ 13-Feb-2017 ]

With distance learning in places like USA and Canada, yes, timezone should become increasingly important....

Comment by Sam Ottenhoff [ 13-Feb-2017 ]

Okay I added a couple of commits to the PR to align more closely with existing behavior in Assignments + Announcements.

If server is in EST timezone and user is in CST timezone and has modified Sakai preferences to use America/Chicago:

  • All times should display in central timezone
  • Editing should be done in the central timezone. E.g., if you input 1:00pm to the timepicker as the open date, the assessment should open at 2:00pm Eastern
Comment by Gnapika Reddy Kudumula [ 10-Aug-2017 ]

Should we need to change the time&date in preferences as well to reproduce the issue?

Comment by Kristlyn Dalton [ 11-Aug-2017 ]

I was able to reproduce this issue following the steps outlined above.

Comment by Neal Caidin [ 14-Aug-2017 ]

Kristlyn Dalton , which version of Sakai were you testing on? Thanks.

Comment by Kristlyn Dalton [ 17-Aug-2017 ]

Hi Neal. I used Sakai Nightly to test. (https://trunk-mysql.nightly.sakaiproject.org/portal/)

Comment by Neal Caidin [ 18-Aug-2017 ]

Thanks Kristlyn Dalton .  Can you please try testing again? But this time add in a step, after step #1, add a step #1a.  Go to Sakai Home -> Preferences -> Time Zone and set the time zone to match the time zone of your local PC clock. If you do that, which would make sense to me, then you should not see that behavior. 

To me that seems like the expected user setting , for PC to match Preferences. 

 

Comment by Kristlyn Dalton [ 31-Aug-2017 ]

Hi Neal Caidin. Sorry for the delay. I tested again and changed my time zone preference to match the time on my computer. You are correct, I did not see the same behavior. When I created the exam I set the open date for 8am (my preferences and computer are CST). Then when I selected Save Settings and Publish, the open date was listed as 9am (EST). I selected Edit Settings and Save and Publish again and the open date time remained (9am). After publishing the exam the open date showed as 8am. It looks like when the time zone preference matches the time zone on the computer, the time does not increase each time settings are edited.

Comment by Neal Caidin [ 31-Aug-2017 ]

Thanks Kristlyn Dalton , I think we will call this one verified for now then. If someone disagrees we can always have more discussion.

 

Comment by Austin [ 10-Jan-2018 ]

I recommend backporting this patch to 11.x.

Even if the server, laulima preferences, os timezone are all set to the same time zone (e.g. HST), this bug will still cause the dates to appear incorrectly. What looks like is happening is that after you save an assessment with e.g a due date, then preview, the displayed due date will appear in UTC time. UTC time will also be displayed when you edit the settings. But what's worse is if you don't change anything (e.g. you hadn't noticed the difference in date and were editing some other setting) and re-save, the date will be resaved further into the past. Which I think happens because the date is displayed in UTC, but when you save, samigo thinks it's in local or the preferences time zone and re-converts it to UTC again.

Comment by Austin [ 10-Jan-2018 ]

It looks like this patch (applied to 11.4) does fix the problem I mentioned above where server, laulima preferences, and os timezones are all set to be the same.

But I think as it was mentioned above, if all three time zone settings are different, we'll see the issue again (reproduced on the 12.x nightly server). But also stated, if the user sets their Laulima preferences and OS timezone to be the same, the problem goes away, which I think would normally be fine.

However, what about the case where someone is traveling temporarily and their OS time zone is being set automatically? Perhaps that's rare? But they'll run into the issue again.

Comment by Sam Ottenhoff [ 13-Mar-2018 ]

Testing on 11.x would be great .....

Generated at Mon Sep 16 16:10:29 CDT 2019 using Jira 8.0.3#800011-sha1:073e8b433c2c0e389c609c14a045ffa7abaca10d.