Take these two excerpts from the Registry of two different machines, from 

As you can (hopefully) see, the Std key (StandardName) on both of these timezones differ, by the dash.

If am am trying to obtain the Infragistics.Win.TimeZoneInfo from the System.TimeZoneInfo, the only way I can see to do this is using the FromStandardName function, i.e.

foreach (System.TimeZoneInfo tziSystem in System.TimeZoneInfo.GetSystemTimeZones())
    {
        if (tziSystem.Id == "UTC")
        {
            Infragistics.Win.TimeZoneInfo tziInfragistics = Infragistics.Win.TimeZoneInfo.FromStandardName(tziSystem.StandardName);
            Debug.Assert(tziInfragistics != null, "Unable to look up TimeZone");
        }
    }

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.  

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? 

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

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

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. 

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.