2

I'm failing to get the Bing Maps API working. I'm inputting a query "How do I get from Annandale to Eastwood (Sydney) using public transport?" and getting results that have completely different times to what I queried.

The API is documented here:

https://msdn.microsoft.com/en-us/library/ff701717.aspx

and here:

https://msdn.microsoft.com/en-us/library/ff701718.aspx

The documentation fails to specify what date format the responses are in, but I presume this is correct:

http://weblogs.asp.net/bleroy/dates-and-json

So here's my query: http://dev.virtualearth.net/REST/V1/Routes/Transit?wp.0=-33.886620,151.171720&wp.1=-33.785780,151.075740&timeType=Departure&dateTime=11:43:00&maxSolns=3&output=json&key=(redacted)

Note that I redacted our API key, for obvious reasons.

Note that I'm requesting a bus at 11:43am. I've tried this in conjunction with a date and without a date, it makes no difference.

I get a response which looks quite valid at first glance, but it's giving me times like this: "time":"/Date(1427222880000-0700)/"

...which would be reasonable if my query time was 5:43, but it's not. That date format clearly indicates "milliseconds since 1970, UTC" (in desperation I tried adding & subtracting 7 hrs, but got nothing meaningful). The documentation clearly says my time of 11:43 should be specified in the local timezone, i.e. just as "11:43".

Proceeding on the assumption that the Bing documentation is wrong or that the implementation is wrong, I tried arbitrarily adding 6 hrs or subtracting 18 hrs from my query time (that necessitated adding the date into the URL), but I got nothing that made sense. I can't get any correspondence between my API results and the public Bing browser app.

I couldn't find out who to ask from Microsoft either.

Any ideas?

Tim Cooper
  • 10,023
  • 5
  • 61
  • 77
  • 1427222880000 is Tue, 24 Mar 2015 18:48:00 GMT. 0700 is the current timezone in Redmond, WA. This is Mar 24 2015 11:48:00 in Redmond, WA. Is this not meaningful? – Jayen Mar 25 '15 at 23:33
  • Have you tried adding the timezone to the input dateTime ? – Jayen Mar 25 '15 at 23:38
  • I'm not in Redmond, neither are my origin or destination locations. According to the API documentation, there is no provision to add the timezone to the input parameter 'dateTime', it's always understood to be local time at the relevant lat/long. What syntax would you propose I try? – Tim Cooper Mar 27 '15 at 02:51
  • i would suggest your try the output syntax. milliseconds+timeoffset. or try one of these: https://msdn.microsoft.com/en-us/library/system.datetime.parse.aspx#StringToParse – Jayen Mar 27 '15 at 07:09
  • The output syntax gives me: ,"dateTime: This parameter value has an invalid format." – Tim Cooper Mar 28 '15 at 22:10
  • have you tried https://social.msdn.microsoft.com/Forums/en-US/home?forum=bingmapsservices ? – Jayen Mar 29 '15 at 06:02
  • I also ran into something ilke this: https://stackoverflow.com/questions/52308530/how-to-correctly-handle-date-0700-date-format-from-bing-using-moment It looks to me like the timezone handling in Bing Routing is seriously whacky. If I submit departure time with a local timezone (+1000) it interprets it as completely the wrong time. If I leave the timezone off, or use California time (-0700), the time is handled as if it were a Melbourne time, perfectly. – Steve Bennett Sep 14 '18 at 01:39

3 Answers3

1

I have the following solution that may or may not be reliable, and it violates the specs, but it works for now:

  1. Add the 0700 to the timestamp, i.e. convert it to a "negative 7 hrs". If there was a '+' instead of a '-' then the sign would be reversed, although I suspect pluses are never used (dunno how they'd change the sign).

  2. Subtract the timezone offset of Sydney i.e. -11 hrs (i.e. add 11 hrs).

This then gives me something I can put into a Java 'Date' instance, i.e. "new Date(x)' which represents a time independent of any timezone.

I was hoping I could use the "milliseconds since UTC" and ignore the "0700" because our system stores these times in "milliseconds since UTC", but I couldn't get that to work.

Everything is consistent with the hypothesis that Bing is incorrectly parsing the Sydney GTFS files, interpreting them as Redmond times instead of Sydney times.

Tim Cooper
  • 10,023
  • 5
  • 61
  • 77
0

As mentioned in the comments the date information being returned is correct. The format of the returned DataTime value in the JSON response is an OData DateTime: 

“/Date([ticks][“+” | “-” ][offset])/”

[ticks] = number of milliseconds since midnight Jan 1, 1970

[offset] = number of minutes to add or subtract

You can find documentation on this here: http://www.odata.org/documentation/odata-version-2-0/JSON-format/

rbrundritt
  • 16,570
  • 2
  • 21
  • 46
  • The date information does not make any sense relevant to the input dateTime I gave (11:43 Sydney time --> first bus is 11:48 Redmond time?) Therefore I assume I have used the incorrect input time. Do you know what should I specify for the input time? The API clearly states that "11:43" will be interpreted as 'local' time, so it seems it's a bug or incorrect documentation. – Tim Cooper Mar 27 '15 at 02:54
  • As Jayen mentioned, the time that is returned is 11:48am local time which makes sense. – rbrundritt Mar 27 '15 at 15:34
  • @rbrunditt This does not make sense. I don't even know what timezone you are referring to when you use the word "local time" - Sydney time? Redmond time? How can Redmond time be considered 'local'? Did you read my comment above? Right now, Bing is telling me "there is no bus for 13 hours". – Tim Cooper Mar 28 '15 at 22:07
  • "Local Time" is the time for where the transit provider operates. i.e. if you are searching for a route in Sydney and pass in a time of 1pm, it will be 1pm Sydney time. The JSON response will return an OData dateTime object which has ticks since Jan 1, 1970 and a time zone offset. See this for more info: http://stackoverflow.com/questions/3818719/how-to-handle-json-datetime-returned-from-wcf-data-services-odata – rbrundritt Mar 30 '15 at 18:57
  • @rbrunditt Ok, thanks. So Bing really is saying that there is no bus for 13 hours and 5 minutes. Have you ever used this Bing API? Does it work for you? – Tim Cooper Mar 31 '15 at 23:41
  • You passed in a request with a time of 11:43am and the first bus it returns is for 11:48am. A bus in 5 minutes seems pretty reasonable. The reason why it uses a timezone of -7 is that is where the calculation is likely happening. Converting the time to the specified timezone in the response will provide you the local time where you are. – rbrundritt Apr 01 '15 at 18:43
  • According to the documentation, I can ignore the timezone offset and only consider the "milliseconds since midnight London 1970". However, this does not work. The workaround to this Bing bug involves me assuming that the timezone offset they incorrectly give in the response is also the offset they incorrectly use when parsing the GTFS files. See my answer above. If you have written code which parses Bing Maps Transit responses then please post it. – Tim Cooper Apr 02 '15 at 03:56
0

The second link you gave says:

The JSON response returns departure and arrival times as DateTime strings, such as 1318005467000-0700. The first integer in the string (1318005467000) represents the number of seconds since 12:00:00 midnight, January 1, 1970 UTC. The remainder of the string (-0700) represents an offset in hours that you must apply to get the local time. For example, the integer 1318005467000 represents the time '10/7/2011 4:37:47 PM'. When you apply the -0700 offset, you compute the local time as '10/7/2011 9:37:47 AM'. For more information, see DateTime Structure.

So it's 11:48 local time. (Don't ask me for a definition of 'local'.)

Jayen
  • 5,653
  • 2
  • 44
  • 65
  • The date information does not make any sense relevant to the input dateTime I gave (11:43 Sydney time --> first bus is 11:48 Redmond time?) Therefore I assume I have used the incorrect input time. Do you know what should I specify for the input time? The API clearly states that "11:43" will be interpreted as 'local' time, so it seems it's a bug or incorrect documentation. – Tim Cooper Mar 28 '15 at 22:08
  • you gave 11:43 "local" time and it returned 11:48 "local" time. while -0700 should mean redmond, nowhere in the docs does it say it does. – Jayen Mar 29 '15 at 06:01
  • It returned 5:48 Sydney time, not 11:48. – Tim Cooper Mar 31 '15 at 00:12
  • How did you get 5:48? – Jayen Mar 31 '15 at 03:22
  • I was given: "/Date(1427222880000-0700)/" So I put 1427222880000 into http://www.epochconverter.com/ and got: "Your time zone: 3/25/2015, 5:48:00 AM GMT+11:00 DST". My timezone is Sydney: I'm sitting in Sydney and my query is to & from Sydney. – Tim Cooper Mar 31 '15 at 23:45
  • you didn't subtract 0700 to get 11:48 – Jayen Apr 01 '15 at 02:56