I looked into this a bit more, and I don't think it will work. Infragistics.Win.TimeZoneInfo doesn't store the Id. 

I'm straining my brain to wrap my head around what's going on here. And I can't honestly claim to be an expert on TimeZone or StandardNames or Ids. 

But it seems like you are making a the assumption here that the Id on one machine will always match up to the same StandardName on another machine, and that's not the case. But that's just the way MS is setting up the registry, and I'm not sure what we could do about that...

Except to give you some facility to get a TimeZoneInfo from the Id, instead of a StandardName, which I think is what you were asking for in your original post. Is that right? 

Is this blocking or is the work around sufficient? 

Thanks for your in-depth analysis.  I've done some more digging, and it looks like it might be an issue with the System TimeZoneInfo.FindSystemTimeZoneById.

What we're doing, is storing the System TImeZone Id in a database, which in this case is "UTC".  To then get back to the Infragistics timezone, we're first getting the system timezone with System.TimeZoneInfo.FindSystemTimeZoneById("UTC"), and then using the StandardName from that timezone to look up the Infragistics equivalent.

But it seems that on some machines, the System TimeZone returned isn't what I would expect.  Here's an example:

(Sorry, the hidden line is:
if (tzi != null) tziInfragistics = Infragistics.Win.TimeZoneInfo.FromStandardName(tzi.StandardName);
)

As you can see, when we try to get the timezone back from the ID, it returns a different object to what we'd expect, and we're then trying to look the Infragistics zone up by the name "UTC".

This doesn't happen on all machines - I tested it on another and it successfully returned the correct System TImezone, and from there, the Infragistics one is looked up successfully.

Aside from explicitly working around this case, I can't think of a decent solution to this.  Storing the Id seems the sensible thing to do, given this should be consistent across machines.  

So I did some testing on my machine and I ran this code: 
var timeZones = System.TimeZoneInfo.GetSystemTimeZones();

And I looked at the list, and on my machine, I have "Coordinated Universal Time" on the list without the dash.

So then I looped through all the timeZones in the list and called Infragistics.Win.TimeZoneInfo.FromStandardName passing in the StandardName of each one. And I get an Infragistics.Win.TimeZoneInfo object every time. They match up fine.

So you seem to be saying that passing in the name without the dash does NOT work for you on your machine. But that's the opposite of what I am seeing on my machine - at least in the case without the dash. I don't have another machine to test, but I went into the registry and found the key for UTC and changed the "Std" value from "Coordinated Universal Time" to "Co-ordinated Universal Time" and tried again, and that also works fine. So that seems to prove that both the DotNet Framework and our list of TimeZoneInfos are both coming from the registry on the machine.

Just to be sure, I stepped into our FromStandardName method and I can see that when we build the list, we are building the list of TimeZoneInfos by the StandardName and we are pulling those names from the registry. So on any given machine, the StandardNames of our TimeZoneInfos will always match up. 

I can also see that our code has a fallback mechanism so that if we are unable to access the registry for whatever reason, we keep a hard-coded list of the TimeZoneInfo data. But neither "Coordinated Universal Time" nor "Co-ordinated Universal Time" is on the backup list as far as I can see. 

So if your call to FromStandardName is failing, it can only be for one of two reasons: 

1) The application failed to access the system registry and was forced to fall back to the hard-coded list. In which case, neither "Coordinated Universal Time" nor "Co-ordinated Universal Time" would work, since neither is on our backup list. 
2) You are not getting both lists from the same machine. Like maybe you have a cached list or you are storing the StandardName of the TimeZone on one machine and trying to call FromStandardName on some other machine where it doesn't exist.