I am storing schedules in the database as a day of the week, hour and minute. When the data is read we create a DateTime
object for the next occurrence of that
DateTimeOffset
itself isn't really DST-aware, but TimeZoneInfo
is. A DateTimeOffset
represents a fixed instant in time - so you get to a DateTimeOffset
via something that is time zone aware. In other words, if I asked for a DateTimeOffset
now in the UK, I'd end up with something with an offset of +1 hour from UTC. If I asked for a DateTimeOffset
for some time in December in the UK, I'd end up with something with an offset of 0 hours from UTC.
If you change your database to include the offset and you create the DateTimeOffset
from the user's chosen DateTime
(which should be of kind "unspecified") and their time zone, then that should give you the correct offset taking DST into account.
One thing to be aware of though: if I schedule something now for "2 years time" and you determine the offset now, that offset may not be correct in the future - for example, the government could change when DST applies, and obviously that's not going to change what's stored in your database.