"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.
Get Timezone Enum Windows does not contain an entry for America/Indiana/Indianapolis
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.
2 answers
Sort by: Most helpful
-
rbrundritt 18,266 Reputation points Microsoft Employee
2020-09-09T23:34:01.423+00:00 -
Edward Swangren 6 Reputation points
2020-09-10T15:30:59.873+00:00 @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?