Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Somewhat misleading title, I know. Never actually wanted to store TimeZoneInfo object themselves: rather, I want to store some culture-neutral identifier, which can then be later used to reconstruct an instance of TimeZoneInfo.
Currently, I’m storing the value of TimeZoneInfo.Id property and it seems to be OK both on English and Russian versions of Windows, but I just wanted to make sure I do the right thing.
Yes,
Idis a non-localized identifier, so that’s an appropriate thing to store.You should be aware of one possible problem though: identifiers can change over time. I don’t know whether it’s an issue in Windows time zone identifiers, but it certainly occurs in the Olson (zoneinfo) database. For example, I was recently looking at an issue caused by “Pacific/Ponape” changing to “Pacific/Pohnpei”.
I suspect that as Microsoft has tighter control over the IDs, they’re more likely to remain the same – but even so, countries can change their names, split into different countries (potentially creating new time zones) etc.
I’m not suggesting any fixes for this problem – just highlighting it as a potential issue. Storing the ID is probably the best approach available, but be aware of the potential risks…