none
What exactly can be in TimeZoneDefinition's "Id" field? RRS feed

  • Question

  • In the documentation for TimeZoneDefinition, found here: https://msdn.microsoft.com/en-us/library/office/dd899488(v=exchg.150).aspx

    The field "Id" is documented too vaguely for my purposes: "Represents the unique identifier of the time zone"

    I originally took this to mean that it corresponds to the names in CLDR's "windowsZones" file. These zones are all in English and up to today, all the data we had seen contained values which were in this file.

    Today, I found data which has the value "Hora oficial do Brasil" in one of these, so now I have to ask, is it really OK for localised strings to end up in these as well? Because that complicates things!

    If localised names really can end up in here, does Microsoft have some kind of repository of all time zone information in all languages, so that we have enough information to map them to a tzdb ID?

    The alternative would be to look at the TZRule values and try to pick the tzdb zone which has the most similar rules. This is undesirable for not just because it sounds difficult, but because often multiple zones have the same offset data yet people get stroppy if we show the wrong time zone to them.


    Monday, January 18, 2016 1:44 AM

Answers

  • Hi Trejkaz,

    After doing my own testing with MailboxCulture, I find that this doesn't change the language/culture of the id's handed back from EWS. So I believe your are right, the Id's should be in English and this string you see seems a little anomalous. However, researching this further I find that the using the timezone rules to find the same timezone in the local registry using the aforementioned API's is your safest bet unless you can find a 3rd party respository or db that has such a global set of localized strings. I see other folks doing the same on other forums. Out of curiosity, I would be interested to know how the Id was returned: what call was made against which version of Exchange?

    Best regards,
    Tom Jebo
    Sr Escalation Engineer
    Microsoft Open Specifications

    Friday, January 29, 2016 10:51 PM
    Moderator

All replies

  • Hello Trejkaz,
                        Thank you for your inquiry about Microsoft Office protocols. We have created an incident for investigating this issue. One of the open specifications team member will contact you shortly.

    Regards,
    Sreekanth Nadendla
    Microsoft Windows Open specifications

     
    Monday, January 18, 2016 3:43 AM
    Moderator
  • Hi Trejkaz,

    I will look into this for you and get back to you shortly.

    Best regards,
    Tom Jebo
    Sr Escalation Engineer
    Microsoft Open Specifications

    Tuesday, January 19, 2016 5:33 AM
    Moderator
  • Hi Trejkaz,

    thanks for your patience on this issue. The database used by Outlook/Exchange (via .net) to look up timezones is:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones 

    Which is localized for the machine of the running software. That means that technically, what you'd have to do is to change the local machine's language to Brazil/Portugese and then do the look up for the "Hora oficial do Brasil" id string you're seeing. If you do the lookup on a different cultured/lang machine, like en-US for example, it won't be found.

    You can see an example of this lookup, including the source code, in the EWSEditor released publicly on codeplex:

     https://ewseditor.codeplex.com/

    This code is essentially what Exchange would use for a lookup, for example doing System.TimeZoneInfo.FindSystemTimeZoneById().

    Additionally, on GetServerTimeZones, there is a MailboxCulture element that:

    Specifies a SOAP header that identifies the culture
    to use for accessing the server. The cultures are
    defined by [RFC3066]

    If you are calling GetServerTimeZones, then you might try using this.

    Thanks,
    Tom Jebo
    Sr Escalation Engineer
    Microsoft Open Specifications



    Thursday, January 28, 2016 10:57 PM
    Moderator
  • Hi Trejkaz,

    After doing my own testing with MailboxCulture, I find that this doesn't change the language/culture of the id's handed back from EWS. So I believe your are right, the Id's should be in English and this string you see seems a little anomalous. However, researching this further I find that the using the timezone rules to find the same timezone in the local registry using the aforementioned API's is your safest bet unless you can find a 3rd party respository or db that has such a global set of localized strings. I see other folks doing the same on other forums. Out of curiosity, I would be interested to know how the Id was returned: what call was made against which version of Exchange?

    Best regards,
    Tom Jebo
    Sr Escalation Engineer
    Microsoft Open Specifications

    Friday, January 29, 2016 10:51 PM
    Moderator
  • I'm not sure, nobody ever tells us how to reproduce issues, they just feed us data that doesn't work and expect us to fix it without giving any useful information.

    There's another one today. This time the string is "Australia/Melbourne". Funnily enough, that is a valid tzdb ID, but I wouldn't have expected it ever to occur in MAPI data.

    Thursday, February 4, 2016 10:41 PM
  • Of course, we are doing all of this on a non-Windows platform, so we can't use Windows API calls to get values. I guess we could run a program on Windows that feeds every single time zone through every single available locale, but then if Microsoft add a locale in the future, we would be out of date immediately. :(

    I do think that looking at the rules will be the best bet now, but it doesn't seem like it will be very easy. (Plus, multiple time zones have the same rules, so the mapping will occasionally produce an unexpected result anyway.)

    Thursday, February 4, 2016 10:43 PM
  • Thanks for the follow-up comments Trejkaz.

    Tom

    Saturday, February 6, 2016 12:30 AM
    Moderator