Несколько вводящий в заблуждение заголовок, я знаю. Никогда на самом деле требуемый для хранения TimeZoneInfo
возразите себе: скорее я хочу сохранить некоторый нейтральный в отношении культуры идентификатор, который может затем позже использоваться для восстановления экземпляра TimeZoneInfo
.
В настоящее время я храню значение TimeZoneInfo.Id
свойство и это, кажется, в порядке и на английских и российских версиях Windows, но я просто хотел удостовериться, что я делаю правильную вещь.
Да, Id
является нелокализованным идентификатором, так что это подходящая вещь для хранения.
Однако следует помнить об одной возможной проблеме: идентификаторы могут меняться со временем. Я не знаю, является ли это проблемой для идентификаторов часовых поясов Windows, но это определенно происходит в базе данных Olson (zoneinfo). Например, недавно я рассматривал проблему, вызванную изменением "Pacific/Ponape" на "Pacific/Pohnpei".
Я подозреваю, что поскольку Microsoft более жестко контролирует идентификаторы, они, скорее всего, останутся неизменными - но даже в этом случае страны могут менять свои названия, разделяться на разные страны (потенциально создавая новые часовые пояса) и т.д.
Я не предлагаю никаких исправлений для этой проблемы - просто подчеркиваю ее как потенциальную проблему. Хранение идентификатора - это, вероятно, лучший доступный подход, но помните о потенциальных рисках...
Я не вижу проблемы с хранением идентификаторов, поскольку они, похоже, являются постоянным значением для всей платформы windows - то есть, конкретный идентификатор всегда будет сопоставлен с одним и тем же объектом TimeZoneInfo
, независимо от того, какую версию windows вы используете.
Я не уверен, что делает mono, но я не удивлюсь, если это будет то же самое. Вы всегда можете проверить исходный код класса.
проверьте эти два метода
public static System.TimeZoneInfo FromSerializedString(string source)
public string ToSerializedString()
они должны сохранить как можно больше информации :)