15

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.

Anton Gogolev
  • 113,561
  • 39
  • 200
  • 288
  • not sure but check this may help you : http://blog.sqlauthority.com/2010/07/15/sql-server-datetime-function-switchoffset-example/ – Pranay Rana Aug 10 '10 at 07:33
  • Related question - http://stackoverflow.com/questions/2532729/daylight-saving-time-and-timezone-best-practices – Oded Aug 10 '10 at 07:34
  • One downside of TimeZoneInfo.Id is that some names are confusing. A client thinks there's a bug since the ID value for Dubai (UTC+4) is 'Arabian Standard Time' which is the normal/vernacular name for the time zone in Saudi Arabia (UTC+3). We tell the client that it's correct (and to not look in the database), but it doesn't make us look good ... I think that generally the TZ names are better. – steve Jan 20 '20 at 16:54

4 Answers4

17

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...

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • Is there an integer correspondence to the string Id for TimeZoneInfo? Wonder why they didn't provide an int for Id? – Ray Aug 28 '11 at 21:41
  • @ray247: I'm not aware of any mapping between time zone IDs and integers. – Jon Skeet Aug 29 '11 at 07:08
11

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.

Oded
  • 489,969
  • 99
  • 883
  • 1,009
0

check these two methods

public static System.TimeZoneInfo FromSerializedString(string source)
public string ToSerializedString()

these should preserve as much info as possible :)

skaeff
  • 753
  • 2
  • 13
  • 25
-2

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.

Robert
  • 11
  • 1
  • Of course this just hashes the Id string. If the underlying string changes per the marked answer above; the hash would change. – ProVega Jun 19 '14 at 15:50