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.
I don't see an issue with storing the IDs, as they appear to be a constant value across the windows platform - that is, a specific ID will always map to the same TimeZoneInfo object, regardless of which version of windows you use.
I am not sure what mono does, but I would not be surprised if this would be the same. You can always check the class source code.
Yes, Id is 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...
check these two methods
public static System.TimeZoneInfo FromSerializedString(string source)
public string ToSerializedString()
these should preserve as much info as possible :)