So correct me if I’m wrong here, but the way timezones seem to work is that, when creating an event, you specify a “local” time, then the app translates that time from whatever it thinks your browser’s time zone is into UTC and saves it in the database. When somebody else views the event, the app translates the time in the database from UTC to whatever it thinks their browser’s time zone is and displays that.
I suppose this will at least sometimes work okay in practice, but if somebody creates an event in a time zone other than the one they’re in right now, it will be wrong, and if you’re viewing an event in a different time zone from your own, it’ll be unclear which time zone is meant. Also, Moment.js’s guess as to the user’s time zone is not always reliable.
I think the right way to handle this would be to use the Google Maps API to determine, from the event’s location and the given local time, what time zone the event is in, and then to attach that time zone to the time stored in the database and display it explicitly on the page. Does this make sense?
Yep, that is how it works. This seemed to make the most sense for potential remote events, i.e. when people want to Skype into an event. I think it could totally make sense to instead display the time in the local timezone, but it’s not obviously better to me and would require a bunch of engineering effort. But if someone else feels strongly about it, I would definitely merge a PR and help getting them set up with the codebase and everything to make that change happen. Also if enough people feel that the other way would be better, then I can get around to fixing it.
I do think that in general, focusing on listing events over groups was a mistake. When I get around to fixing our UI, I think the community page should feature groups a lot more prominently than events, which also mostly sidesteps this problem.
So correct me if I’m wrong here, but the way timezones seem to work is that, when creating an event, you specify a “local” time, then the app translates that time from whatever it thinks your browser’s time zone is into UTC and saves it in the database. When somebody else views the event, the app translates the time in the database from UTC to whatever it thinks their browser’s time zone is and displays that.
I suppose this will at least sometimes work okay in practice, but if somebody creates an event in a time zone other than the one they’re in right now, it will be wrong, and if you’re viewing an event in a different time zone from your own, it’ll be unclear which time zone is meant. Also, Moment.js’s guess as to the user’s time zone is not always reliable.
I think the right way to handle this would be to use the Google Maps API to determine, from the event’s location and the given local time, what time zone the event is in, and then to attach that time zone to the time stored in the database and display it explicitly on the page. Does this make sense?
Yep, that is how it works. This seemed to make the most sense for potential remote events, i.e. when people want to Skype into an event. I think it could totally make sense to instead display the time in the local timezone, but it’s not obviously better to me and would require a bunch of engineering effort. But if someone else feels strongly about it, I would definitely merge a PR and help getting them set up with the codebase and everything to make that change happen. Also if enough people feel that the other way would be better, then I can get around to fixing it.
I do think that in general, focusing on listing events over groups was a mistake. When I get around to fixing our UI, I think the community page should feature groups a lot more prominently than events, which also mostly sidesteps this problem.