Как NodaTime обрабатывает будущие даты, если наше правительство изменит время начала DLS?

Во-первых, вам нужно будет обновить данные, чтобы узнать об изменении и получить соответствующий IDateTimeZoneProvider в вашем коде. Инструкции для этого приведены в руководстве пользователя, но мы надеемся, что в будущем это будет проще. Особенно:

• Мы уже создаем и публикуем новые файлы данных, когда IANA публикует новую версию исходных данных.
• Мы планируем создать пакет Nuget, который также можно будет обновлять при каждом новом выпуске исходных данных; это позволит пользователям, у которых есть регулярные развертывания, выбирать последнюю версию для каждой сборки, оставляя относительно небольшое временное окно, в течение которого она устаревает.
• Мы можем предоставить вам строительные блоки для опроса и самообновления вашего приложения в той или иной форме.
• Мы, скорее всего, будем размещать файлы на CDN, а не только на веб-сайте Noda Time, как сейчас.

Так что это вопрос получения новых данных. Другое дело, как вы его используете. Если вы сохранили UTC в своей базе данных, вы получите другое местное время, когда позже примените новые данные часового пояса к тем же временным меткам. Если это не то, что вы хотите, если ваше приложение имеет дело с пользователями, планирующими события по местному времени, тогда вы должны сохранять местное время и часовой пояс, чтобы изменение данных часового пояса означало изменение момента времени, когда событие происходит, а не изменение местного времени, в которое оно происходит. Конечно, вам нужно подумать о том, что произойдет, если кто-то запланировал событие на местное время, которое должно было состояться, но позже оказалось «пропущенным временем», когда часы скорректированы за его пределами. . Noda Time не может сделать этот выбор за вас, но позволяет достаточно легко выразить свое решение с помощью ZoneLocalMappingResolver делегат, возможно созданный или полученный с помощью класса Resolvers.