Somewhat misleading title, I know. Never actually wanted to store TimeZoneInfo
object themselves: rather, I want to store some culture-neutral identifier, which can
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...
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.
check these two methods
public static System.TimeZoneInfo FromSerializedString(string source)
public string ToSerializedString()
these should preserve as much info as possible :)
I simply used TimeZoneInfo.Id.GetHashCode(). According to tests, this generates unique integer ID's that can be stored in a DB. You can also build a Dictionary with keys being these hash codes and values being the original ID strings to make reverse lookup easier.