Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Local timezone #310

Open
torotil opened this issue Jan 3, 2024 · 4 comments
Open

Feature request: Local timezone #310

torotil opened this issue Jan 3, 2024 · 4 comments

Comments

@torotil
Copy link

torotil commented Jan 3, 2024

It’s a bit of a inconvenience to need to take care of time zones when creating the data for the YAML files. Even more so because dance events are usually in person at a specific place where the timezone to use is kind of obvious

I’d propose to …:

  1. Move the timezone information to an extra field.
  2. Accept unix locales (eg. Europe/Vienna) for this field instead of just offsets.
  3. Implement a mapping of country/city to default timezone.

Any of those would improve the editing experience.

@qwandor qwandor transferred this issue from qwandor/dancelist-data Jan 3, 2024
@qwandor
Copy link
Owner

qwandor commented Jan 9, 2024

Those seem like reasonable ideas, I'll have a go at implementing them. The change is going to require changing all existing files though, which is a pain.

@qwandor
Copy link
Owner

qwandor commented Jan 9, 2024

I've started looking into this, and unfortunately daylight savings time boundaries make it tricky.

Just moving the timezone offset to a field by itself doesn't work, because sometimes an event will run over a DST boundary, e.g. from 2024-03-30T20:00:00+00:00 to 2024-03-31T04:00:00+01:00, where the start and end UTC offsets are different. Having a separate field with the timezone name rather than the offset (e.g. Europe/London in this example) almost works, except that there are some times right on the boundary that are ambiguous (and some that don't exist at all). E.g. 2024-10-27T01:30:00 in Europe/London refers to two different times, either before or after the offset change. It's unclear how to handle this. I could always pick one, but that makes it impossible to correctly enter events starting or ending within a particular hour each year.

Your third suggestion of mapping cities to default timezone is possible (as part of the add event form), though is more of a pain without timezone names being stored in events.

@torotil
Copy link
Author

torotil commented Jan 10, 2024

Ok, I see the edge cases 🤔

Would it be an option to still allow the start and end time to specify an offset? Then this could be used to disambiguate the rare edge cases while still not needing to care for almost all events. So my suggestions would just be a fallback for when there is no offset specified. This would also remove the need to migrate existing files.

NB: As an organiser I would expect half of my audience to just understand the wrong time in those cases anyway — even if I list the time in an unambiguous way. 😂

@qwandor
Copy link
Owner

qwandor commented Jan 15, 2024

#315 is now live, https://folkdance.page/add will automatically set the timezone based on the country and state.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants