Ah ok, that makes sense.  I think I'm okay for the time being, but will get back in touch if it becomes a problem later on.  Thanks again for your help.

So it looks like what probably happened here is that there were no Ids when we created the TimeZoneInfo class. And the Id was added by Microsoft later on (in CLR3.5). So that's why we never had them.

Working around the issue by checking for both strings is still your best and fastest way to get your application going. But if you think it would be important to have this in some future release, we could probably add it in pretty easily.

Thanks Mike.

I think working around it and just checking for both strings is probably your best bet right now. That's certainly the fastest way for you to get going. 

I sent an inqury to the guys who wrote this code to see if anyone remembers why we are using StandardName instead of Id. There's probably a good reason, but I don't know what it is, myself. 

I tried using reflection to get the entire list of TimeZoneInfo objects so you could loop through the manually and find the one with the matching Id, just as another potential workaround. But that doesn't work because Infragistics.Win.TimeZoneInfo doesn't even store the Id. So there's no way to match up to an Id even if you could get the entire list. 

Hi Mike.

I'm making the assumption that timezone Ids are consistent across different machines, not StandardNames.  It seems the latter is not the case, which is why it seems somewhat odd that Infragisics implement a FromStandardName function, rather than a FromId function on the TimeZoneInfo class.  I think doing so would remove any ambiguity and prevent null being returned.

Thanks Michael, I think the workaround I have just now is sufficient, but there may be other examples aside from UTC where this occurs, in which case it could crop up again.

Campbell