Hours response not reflecting the end of DST, website hours off by 1

[jvine]

Since the time change Nov 5, the website hours have been off by one - they didn't fall back. Hours service and SearchWorks are both displaying the correct hours.

Drupal dev says the problem is in the hours response:
https://library-hours.stanford.edu/api/v1/library/green/location/library-circulation/hours/for/today

[{"id":146319,"day":"2017-11-07","weekday":"Tuesday","opens_at":"2017-11-07T08:00:00.000-08:00","closes_at":"2017-11-08T01:00:00.000-08:00","type":"Fall Quarter","notes":"","location_slug":"library-circulation","location_id":12,"closed":false}]

The offset is -8 when it should be -7. My guess is SearchWorks is just reading the time without looking at the offset; but Drupal's standard library uses the offset, and we'd have to do a hacky overrride to prevent it.

What's the effort involved in making Hours adjust the offset w DST start/end?

[jkeck]

Just starting the convo here. I don't have a ton of experience dealing with DST and time parsing, but it seems like we're doing the right thing?

Because we're in PST right now the offset is -8. It would be -7 when in Daylight Savings Time which just ended.

https://en.wikipedia.org/wiki/Pacific_Time_Zone

Now, if the API was responding with -7 when it was actually DST is another question, but I believe that would mean Drupal had been accounting for that anyway (outside of DST).