You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
The text was updated successfully, but these errors were encountered:
We need to better handle time in scheduling (scenario, simulation)
The text was updated successfully, but these errors were encountered: