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

Summer time is not correctly handled by our scheduling #1793

Open
guillaumejparis opened this issue Oct 31, 2024 · 0 comments
Open

Summer time is not correctly handled by our scheduling #1793

guillaumejparis opened this issue Oct 31, 2024 · 0 comments
Labels
bug use for describing something not working as expected
Milestone

Comments

@guillaumejparis
Copy link
Member

We need to better handle time in scheduling (scenario, simulation)

Storing things in UTC is usually the right solution if something happened in the past as a one-off event. It means that everyone, everywhere, can agree when something happened.

But for future, recurring, events, it doesn't work, for the exact reason you've said.

You should not store offset information with the times (because the offset will change depending on daylight savings, it's not a single fixed number for a specific time), so use a DateTime instead of a DateTimeOffset. And then, along with the DateTime, you need a TimeZoneInfo. This represents the time zone in which the shop is located, and it handles clock changes due to daylight saving. You can call its BaseUtcOffset to find out the (current, including daylight savings) offset between that time zone and UTC, for example, or GetUtcOffset(DateTime) to find out the UTC offset at a particular date/time.

For storing data in a database, use a string to represent the time zone. To convert that string to a TimeZoneInfo you can use TimeZoneInfo.FindSystemTimeZoneById(). To find the list of valid IDs that you can store in the database, you can use TimeZoneInfo.GetSystemTimeZones().Select(tz => tz.Id)

@guillaumejparis guillaumejparis added bug use for describing something not working as expected needs triage use to identify issue needing triage from Filigran Product team labels Oct 31, 2024
@EllynBsc EllynBsc removed the needs triage use to identify issue needing triage from Filigran Product team label Oct 31, 2024
@EllynBsc EllynBsc added this to the Bugs backlog milestone Oct 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug use for describing something not working as expected
Projects
None yet
Development

No branches or pull requests

2 participants