search

DigitaleGesellschaft / jekyll-theme-conference

Jekyll template for a conference website containing program, speaker, talks and room overview
MIT License
64 stars 59 forks source link

Set program initial day based on local TZ, not UTC #37

Closed echeran closed 1 month ago

echeran commented 2 months ago

Problem: When using this theme over here in the America/Los_Angeles time zone (GMT-8 / GMT-9), for a 2-day event, during the event on the first day, the program page defaulted to showing the 2nd day. And on the 2nd day of the event, the program went back to showing the 1st day.

Tracing the problem down, it looks like the JS Date API doesn't provide good functions for converting between UTC and local time zones well. The code in program.js was taking the user's days' strings, which are representing local time zone days, instantiating a Date in JS (which only creates a UTC time zone date), and then compares the day part to the user's JS runtime's current Date instance's day part.

This issue probably doesn't manifest for people whose time zone is close enough to GMT / UTC.

Solution:

Treat the user provided day string from the program as the day in the local time zone. Construct an analogous string in the user's JS runtime and then do string comparison. This works around JS's lack of time zone support in the Date API to compare 2 "local dates" (dates that are not representing an absolute time pinned to the UTC time zone).

lorenzschmid commented 1 month ago

Thanks for looking into this and proposing a solution. Indeed, the template is struggling with timezone, not only for showing the correct date in the program but also for the live indications as someone noticed already earlier (see #32).

I decided now to properly fix it by using UTC timestamps everywhere and calculating these timestamps correctly based on the local timezone (or overwritten via site.conference.tz property). This simplifies a lot, and so I also got rid of the "using the current date and setting the time to midnight" inside program.js. As you pointed out correctly, this approach was flawed. You can find the fixed implementation as version 3.6.6 already part of main.

As such, the proposed changes here are no longer required. Thank you anyway!

echeran commented 1 month ago

Thanks for the update, and also thanks for the other work that was done already to fix the problems.