Get Timezone Enum Windows does not contain an entry for America/Indiana/Indianapolis

Question

The following query

https://atlas.microsoft.com/timezone/byCoordinates/json?subscription-key={key}&api-version=1.0&query=39.49794,-87.39201&limit=1

Returns

{
    "Version": "2020a",
    "ReferenceUtcTimestamp": "2020-09-09T18:02:37.1896138Z",
    "TimeZones": [
        {
            "Id": "America/Indiana/Indianapolis",
            "Names": {
                "ISO6391LanguageCode": "en",
                "Generic": "Eastern Time",
                "Standard": "Eastern Standard Time",
                "Daylight": "Eastern Daylight Time"
            },
            "ReferenceTime": {
                "Tag": "EDT",
                "StandardOffset": "-05:00:00",
                "DaylightSavings": "01:00:00",
                "WallTime": "2020-09-09T14:02:37.1896138-04:00",
                "PosixTzValidYear": 2020,
                "PosixTz": "EST+5EDT,M3.2.0,M11.1.0",
                "Sunrise": "2020-09-09T07:25:27.281-04:00",
                "Sunset": "2020-09-09T20:08:16.979-04:00"
            }
        }
    ]
}

Id America/Indiana/Indianapolis is not returned in the response from /timezone/enumWindows. It does however contain an entry for America/Indianapolis. Same for America/Kentucky/Louisville as returned from /search, but which is America/Louisville in the enumeration.

Answer

"America/Indiana/Indianapolis" is the IANA timezone code. The Azure Maps timezone service favors IANA timezone codes as they are an international standard that even the Windows team is recommending people use rather than the legacy Windows timezone codes. As such, there is no IANA to Windows timezone service in Azure Maps.

Answer

@rbrundritt I suppose I don't quite understand. The timezone service is returning two incorrect iana ID's from /enumWindows. It's including iana ID's in there, so I'm not sure how this is not a bug. In the response from /timezone/gettimezoneenumiana we do in fact get an alias for them, e.g.

{  
    "id": "America/Louisville",  
    "isAlias": true,  
    "aliasOf": "America/Kentucky/Louisville",  
    "hasZone1970Location": true  
},

As far as I can tell, America/Louisville is not valid (I could be wrong here, far from an expert, but it doesn't exist in the database files I pulled). So, in order to not write a workaround, I would need to call /enumWindows, then call /gettimezoneenumiana, then look for any missing ID that has an alias and fill in the gaps so that I can reliably consume a response from /timezone/byCoordinates? Why include invalid ID's at all?

Share via

Get Timezone Enum Windows does not contain an entry for America/Indiana/Indianapolis

2 answers

Your answer