What does "from today" really mean?

[sungod]

I've searched documentation, community, devnet, github etc., but cannot find an unambiguous definition of the start of timespan parameter.

From devnet, one description is...

t_0	The beginning of the timespan for the data. The maximum lookback period is 1 day from today.

...another...

t_0	The beginning of the timespan for the data. The maximum lookback period is 31 days from today.

...similar wording is found in a few other places.

But "from today" can be interpreted different ways, for instance...

is it from the moment the API call hits the server?

is it from midnight last night local time of each device within scope?

is it from midnight last night UTC?

I'm trying to add Meraki device stats to an existing analytics platform, if it's the latter definition then (assuming it's data with 31 day lookback) I can query on the first day of month N and get all data for month N-1, but if it's one of the other definitions I can't do that, I'd need to do at least two sets of queries per month to avoid a gap in data.

I guess I could write scripts and see what I get back, but I do think it'd be good to have this made clear in the documentation, or at least discoverable with a search here!

[Meraki_John]

Hey @sungod !

While I don't have a definitive answer for you - I did do some testing to work out what the answer is.

I tested using the API call history endpoint which says that t0 is limited to the last 31 days.

What I found that it was actually 32 days from this second (right now). It seems the API server, as it is checking the parameters, checks the epoch time you pass to it with the epoch time from (32 x 86400 seconds ago).

I'm not surprised by the extra day - at Meraki, we nearly always under-promise and over-perform - this way no one complains when the "from today" is ambiguous! 😉

Going on to look at your use case, I would be tempted to build in redundancy in to your scripting, so you have duplication of data that you then de-dupe afterwards, or make the call more frequently, so you can always go back and get missing data later if it occurs. For me personally, this would be better than relying on having one call from your server once per months and then having no redundancy for any type of issue (anything from missing data, through to power failure on the server at the time you are making the call).

So I would do one of the following:

De-dupe model:
Every week:

- Get the last 31 days of data

- De-dupe data

Utilise t1:

Every week:

- check when the last data was

- t0 = the last data point (or 31 days max)

- t1 = now

- check for any duplication at the start of the data set (possibly an overlapping second at the start)

As for a definitive answer to what "from today" means, let's wait to see if one of my colleagues in the API engineering team reply 😄

[sungod]

Thanks for the feedback

I'd also done some testing in the meantime (just using getDeviceSwitchPortStatuses )

If t0 is not specified, then the default timespan 24 hour lookback "from today" means from 'now'

From what you've found, the 31 days lookback "from today" has enough margin for 32x86400 seconds lookback from midnight 'tonight'

i.e. a monthly run on the 1st would always be able to get a full month's data for the previous month, though of course with no safety margin if something delayed the query until the 2nd or later

On the port status data I've gone with taking daily samples just after midnight with t0 at midnight the day before, then assembling into monthly files (to match our customers' reporting frequency), that way if there was a problem it could be recovered, though in this instance a day's missed sample isn't going to matter

I need to make a general wish to be able to set absolute start and end times for sample windows, at least on this call it seems the end is always 'now', as only one of t0 or timespan can be specified according to the documentation