Hi Daniel,

Thank you for the clarification regarding the use_iso_time and format parameters. I tested out the metadata UNIX timestamp filtering and everything looks good to me. Very nice of you to implement that so quickly!

Cheers,
Matt


On Wed, Jan 15, 2014 at 5:00 AM, Daniel Quinn <dquinn@ripe.net> wrote:
I think that there might be some confusion here as to the use of the
`use_iso_time` and `format` parameters, so I'd like to clear those up
now.  I've also patched the code to do what you need though, but one
thing at a time.

The `use_iso_time` flag *only changes the response* to use ISO
timestamps rather than UNIX timestamps (the default).  Additionally, as
UNIX timestamps are the default, setting `use_iso_time=false` does
nothing for you here.

The `format` parameter is only useful for when you're fetching
measurement results and not when you're requesting measurement
metadata.  The `=txt` stuff is a hack we built on top of standard REST
practises in deference to the fact that result datasets can be very big
and near impossible to parse as single JSON units.  For all of the
other calls, the API follows the same path as you'll see with other
REST environments: JSON and XML.  You can access these formats by using
`format=json` and `format=xml` respectively.

As for actually filtering your metadata by `start_time` and `stop_time`
using UNIX timestamps instead of ISO ones, this was a limitation of the
framework we're using.  I've since burned a couple hours today
overriding the default behaviour to allow for using *either* a UNIX
timestamp or an ISO one.  Go ahead and give it a spin.  Let me know if
it works as expected.