measurement start_time and stop_time fields
Hi, For the filter fields such as start_time__lt, stop_time__gte the API at https://atlas.ripe.net/docs/rest/ claims that a unix timestamp should be valid for these but I am seeing the error message "'1389655981' value has an invalid format. It must be in YYYY-MM-DD HH:MM[:ss[.uuuuuu]][TZ] format." I was trying with this query: https://atlas.ripe.net/api/v1/measurement/?limit=20&type=2&format=txt&use_iso_time=false&start_time__gte=1389619981&stop_time__lte=1389655981 Thanks, Matt
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.
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.
participants (2)
-
Daniel Quinn -
Matt Calder