Support for time zones for program, events, etc

[mattstratton]

Localized time zone support is pretty important for virtual events.

The idea I have is that times/dates should be displayed in the browser's time zone.

For some of the elements, this is not terribly hard; we theoretically capture time for the dates with a TZ flag on some things (CFP start/end, etc) although those are less important.

The program page is where it matters the most. Currently, we don't really have any way that we capture this.

With the theme refactor, we can adjust how the program works, and have a proper timestamp for the elements, but we would have to go back through the previous pages/elements and update them.

We could also make it a "going forward" model, where the "old" layout for program would work, but not display localized, etc.

The theory of implementation is that this would have to be done somehow in javascript for the frontend; for each time/date display it would be somehow wrapped in some javascript to convert it, I guess.

[bridgetkromhout]

Good notion. I've spent a bunch of time looking at event pages and cross-referencing trying to answer the question "is this trying to invisibly localize? or is it just displaying some unknown time that is not-me-local?" so I would recommend explicitly displaying TZ.

[mattstratton]

yeah, I mean it would work out to just tell people to put text in their Program page that says "all times are in US CT" or whatever.

I would say that I agree that if we ARE going to correct for TZ (attempt to display in local TZ) maybe the way it works is that the time looks like this (assuming source event is US-CT and detected TZ is US-ET):

08:00 (US-CT) 09:00 (US-ET)

Basically, I've gotten conflicting preference feedback on "should I just say what time zone my event stuff is in or should I convert it for you?", so I'm trying to think of if there is a way to satisfy both.

Maybe we display it by default in the event TZ (labeling somewhere what that TZ is) and have a nice button that says "display times in X time zone" which would convert them on the fly. That is a little bit easier too because we don't have to detect them then. Hmm.

[mattstratton]

And what we could do for the backward-compatibility is that if a timestamp in the code doesn't have TZ information at all, we just ignore all the capability to convert it, and none of that stuff shows up

[bridgetkromhout]

I dislike "convert it invisibly for you" if it doesn't explicitly say what timezone it's displaying times for, since the ambiguity bugs me.

[mattstratton]

Oh, it would definitely show the TZ that is being displayed (whether it was the source or the converted). Sorry if that wasn’t clear! I agree with you completely.

[toshywoshy]

I have actually already used this within another HugoIO project by using the browser timezone and javascript to display the date and time based on the user settings
I will look at the new theme and see if I can add that to it