Description
When editing set dates, the time adjustment - intended to always display times as server time - is set as a constant, but this doesn't handle cases when the offset changes, such as when one time zone observes daylight saving time when the other does not.
Example time zones:
Central Time (US & Canada) - Standard: UTC-6; DST: UTC-5
Mountain Time (US & Canada) - Standard: UTC-7; DST: UTC-6
Arizona - Standard: UTC-7, no DST
The server is set to America/Chicago (U.S. Central), and today is Jan 10, so no daylight saving time.
When the client is on U.S. Central Time, everything appears as we expect.
When the client is on U.S. Mountain Time, it also works; WeBWorK adjusts the underlying time, so it appears as if you're editing in the server's local time.
When the client is in Arizona Time, this is where we see problems. WeBWorK computes the current time difference of 1 hour and it works until a time switch. After March 9th, when most of the U.S. begins daylight saving time, the true difference jumps to 2 hours, but WeBWorK still only adjusts by 1 hour. So, the editor shows a time at 10:59 PM, but it saves a time at 11:59 PM. Similarly, if the user saves a time at 11:59 PM with this incorrect offset, it will be converted to 12:59 AM the next day on the server's time zone.
Sets as they appear on the server:
Central Time client editor (Server time zone):
Mountain Time client editor:
Arizona client editor:
Arizona client changing dates to appear correct in the editor:
Server dates after saving above changes:
Activity
drgrice1 commentedon Jan 10, 2025
What time zone do you have set in site.conf?
jonathonsurles commentedon Jan 10, 2025
Neither the course where this was reported nor my test course override this value, so they also use
America/Chicago
.drgrice1 commentedon Jan 10, 2025
In what time zone is the server located?
jonathonsurles commentedon Jan 10, 2025
U.S. Central, and a
timedatectl
givesTime zone: America/Chicago (CST, -0600)
as welldrgrice1 commentedon Jan 10, 2025
This does not seem to be a valid issue. I just tested this and I see that for the America/Phoenix timezone set in the client, and America/Chicago set on the server, I am getting the correct time zone differential in the browser.
jonathonsurles commentedon Jan 10, 2025
What date(s) were you testing? For me, the issue only occurs when the difference between the timezones at the test date is different than the current distance between the time zones at the current date. As seen in my screenshots: only the dates after the March 9th 2025 shift (and before the Nov 3 2025 shift back) give the wrong offset.
The main issue is the date displayed in the editor being off from the date displayed in the set list.
drgrice1 commentedon Jan 10, 2025
I tested with a date in April 2025 and I see the correct times.
drgrice1 commentedon Jan 10, 2025
Wait, now I am seeing it. I must not have had something configured right in the first test. I will look into it.
Recompute timezone adjustments for a given date.
Recompute timezone adjustments for a given date.
Recompute timezone adjustments for a given date.
Recompute timezone adjustments for a given date.
drgrice1 commentedon Feb 13, 2025
This was fixed in #2655.
@jonathonsurles: You can reopen this if that pull request does not resolve the issue, but I am closing this for now.