Recompute timezone adjustments for a given date.

[drgrice1]

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 while they are currently not observing 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 #2654.

[Alex-Jordan]

Without looking at the code, I'm wondering why the client's time zone should matter at all. Why isn't everything just using the locale specified in the config chain for the course?

Are we trying to support the following? The course is using the America/Chicago locale, but the instructor lives in Phoenix. The instructor opens a date picker and picks a certain time, say 10:00pm on Feb 1. Are we trying to support that the instructor intends the date to be 10:00pm Phoenix time? That seems like something we wouldn't want to do, although I feel like I am missing something here. I would think that even though the instructor is in Phoenix, when they set a time to 10:00pm on Feb 1, that has to be understood as 10:00pm on Feb 1 in Chicago.

What am I missing here? Is it just a quirk about the date picker js relying on the client's time in some way?

[drgrice1]

This code is to ensure that the date/time that is shown in the browser is the server's date/time, and not the client's date time. So this code is making it so that if the instructor opens a date picker and picks a certain time, say 10:00 pm on Feb 1, then that is 10:00 pm on Feb 1 in the server time zone.

[drgrice1]

The point here is that when a UNIX timestamp is converted to a date, localized, and displayed in the browser, the browser uses the client timezone. So by default that is not the server time zone. This code is correcting for that so that the time is the server time zone. The current code generally works for this assuming that the difference between the client time zone and the server time zone is constant throughout the year. That is that the difference between the client time zone and the server time zone in January, say, is the same as the difference between the client time zone and the server time zone in June. However, that is not true for instance in the case that the server time zone is America/Chicago where daylight savings time is observed and the client time zone is America/Phoenix where daylight savings is NOT observed.

[Alex-Jordan]

On Runestone, the value of $siteDefaults{timezone} is 'UTC'. Clients are mostly in the US, sometimes on DST and sometimes not. And UTC doesn't go on DST. And there are a few international subscribers who may or may not have a DST that does not align with the US DST. Does it make sense to you that no one has brought up this issue before under those circumstances?

There is a place in Australia where there is DST, but the differential is 30 minutes instead of one hour. If a client where there using the Chicago WW server, does the change here work for them too?

I guess I am wondering if there just could be a way to tell the browser to use the America/Chicago standard locale in the first place, rather than let it use the local time zone and have to adjust.

[drgrice1]

It is likely that they didn't notice, or that they saw something wrong but didn't say anything.

Presumably this will work for all time zone differentials. That is assuming that the JavaScript knows the time zone and how to deal with it. This uses native JavaScript so that will depend on if the time zone is in the international specifications.

There certainly isn't a way to tell a client's browser that is set to use their timezone to use another timezone. Programatically there is, and that is what we do, and what this pull request is about.

[drgrice1]

@Alex-Jordan: I should point out that there are JavaScript methods for displaying a given time in a particular time zone that is not the time zone set in the client. However, those methods do not give the time differential that is needed for saving the timestamp to the server in the server time zone. That is what this code is doing. It is not just about display.

[Alex-Jordan]

I realized I was not thinking something through. Yes, the Runestone server has $siteDefaults{timezone} = 'UTC' globally, but each institution has its own config file where the appropriate timezone locale is set. So it's unlikely that faculty would have encountered this issue.