-
-
Notifications
You must be signed in to change notification settings - Fork 165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Set editor's time zone adjustment fails for time zones with different daylight saving rules #2654
Comments
What time zone do you have set in site.conf? |
$siteDefaults{timezone} = "America/Chicago"; Neither the course where this was reported nor my test course override this value, so they also use |
In what time zone is the server located? |
U.S. Central, and a |
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. |
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. |
I tested with a date in April 2025 and I see the correct times. |
Wait, now I am seeing it. I must not have had something configured right in the first test. I will look into it. |
Different dates can have different timezone adjustments in the case that the client timezone and server timezone are different and one of those time zones adheres to daylight savings time and the other does not. For example if the client timezone is America/Phoenix and the server timezone is America/Chicago. The America/Phoenix timezone does not adhere to daylight savings time and is always UTC-7 while America/Chicago is UTC-5 during daylight savings time, but is UTC-6 during standard time. So if an instructor is in the America/Phoenix timezone, but working on a server set for the America/Chicago timezone and selects a date that is during daylight savings time, then the current code use an incorrect differential of 1 hour because it uses the same differential for all dates. So this computes the timezone adjustment for a given date so that the correct timezone differential for that time is used. This fixes issue openwebwork#2654.
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:
The text was updated successfully, but these errors were encountered: