JSON webservice returns very large numbers

I have agent code that’s successfully making a JSON webservice call. The results contain unix timestamps in milliseconds from 1/1/1970, which are unfortunately larger than 32 bit integers. Since it’s a JSON block, the agent looks like it’s deserializing the data incorrectly (I’m sure it’s just overflowing an implicit conversion).

How can I get the original value back as a string, at the very least?

Here’s an example API call:
http://api.onebusaway.org/api/where/arrivals-and-departures-for-stop/1_75403.json?key=TEST

Look down in the response data one of the scheduledArrivalTimes. Notice that the number is larger than 2^31. Help!

Here’s a copy of the JSON response. It would be great if the agent didn’t overflow for these large numbers but instead treated them as strings, or arrays, or blobs, or something that I could use to hack off the last 3 characters and then do my own conversion.

What I get is some negative value, such as -2117885200…

Sorry, I can’t help. Just need to express a certain incredulity that someone (onebusaway.org, that is – not blaming you!) would have chosen milliseconds as the appropriate granularity for bus arrival times.

I’m working on what might be a similar project – something which displays predicted bus arrival times for a stop near me. It was going to be my first Imp project, but the data I’m dealing with is XML, and it seems like the Imp stuff is more JSON friendly, so it became my first DigiX project instead. Anyway, sorry for the non-helpful response, but I feel your pain. Good luck with the project!

I’m looking at hosting a node.js app on Heroku which will basically do a divide by 1000 on all the large time stamps to convert them from ms since epoch to seconds since epoch. Seems like some serious overkill but it’s about the only way I could think of which preserved the imp.

@tastewar - thanks. ms for bus times is ridiculous. Minutes is probably good enough for buses and traffic in Seattle.

Is your transit agency available via Nextbus? If so, while Nextbus is XML, apparently (just discovering this…) Proximobus repackages it up in JSON.

http://proximobus.appspot.com/docs.html

Proximobus looks neat. I have Heroku nodejs app doing translations for ms time stamps to seconds and also just added XML parsing endpoint for a local time internet service (takes lat/long). Parsing XML is pretty easy in node - actually it just converts it to JSON.

You can try this: it worked for me at first glance at least :slight_smile:

Basically, whilst the response is still a string, we take advantage of the fact that every time we need to strip the last 3 chars of is prefixed with the string Time":

…we just iterate through the string, find these, remove them, then parse the reply.

local p=http.get("http://forums.electricimp.com/uploads/FileUpload/02/02e9af01e033d1395a36ca3e56f9ff.txt", {}).sendsync(); local q=p.body; local r=0; while((r=q.find("Time\":", r)) >= 0) { // Strip last 3 chars of the time r+=16; q = q.slice(0,r) + q.slice(r+3); } local parsed=http.jsondecode(q); server.log(parsed.currentTime);

That’s a cool idea - and it would allow me to cut out Heroku and have a pure-imp solution.

Thanks for such a simple solution. Got it wired in today in about a minute. Mostly I wanted to not parse the JSON data on the imp/imp cloud but it makes a lot of sense to just clean it up there first. I’m sure the structure of the response won’t be changing anytime soon, so this will continue to work well for the foreseeable future.