Picks_per_day query not reporting correct data when using "date_from" - off by 60-80 seconds

We run a query every 5 minutes to check on the recent picks and ensure items were all scanned and items all had weights, etc. This was working fine until a few months ago, but then we noticed that randomly now it seems to automatically be 5 minutes behind.

For example, if we run the query and use “query {picks_per_day(date_from:“2021-06-25T16:58:50”)”, it will really do it from about 5 minutes and 70 seconds before that (so it would be as if we had entered “T16:52:40”.

Do you know this can be fixed? Or if this was an intentional change by the engineers, do you know the exact seconds that it is behind for that query so we can factor that into our request. Thank you!

If it is helpful, this is an example of a request_id where you can see this (the query was date_from: 19:08:51 but the response has results from before that time (i.e. 19:06:19) :

  • request_id = 60d62a0bd5f24b48a71ec81e
1 Like

Hi Atlatin,
Apologies for the delay, and thank you for the request_id.


"request_id": "60dc93c13465fcae8269a7a0",

picks_per_day(date_from: "2021-06-30 10:10:00", date_to: "2021-06-30 10:11:00")

is giving me results like…

"created_at"=>"2021-06-30T15:06:03" "created_at"=>"2021-06-30T15:06:04" "created_at"=>"2021-06-30T15:06:12" "created_at"=>"2021-06-30T15:06:13" "created_at"=>"2021-06-30T15:06:17" "created_at"=>"2021-06-30T15:06:20" "created_at"=>"2021-06-30T15:06:24" "created_at"=>"2021-06-30T15:06:27" "created_at"=>"2021-06-30T15:06:28" "created_at"=>"2021-06-30T15:06:30" "created_at"=>"2021-06-30T15:06:32" "created_at"=>"2021-06-30T15:06:38" "created_at"=>"2021-06-30T15:06:49" "created_at"=>"2021-06-30T15:06:55"

Further it seems I have to make requests in EST as opposed to UTC to get the results back in UTC.

@atlatin did you come up with any good workarounds?

@kokua Unfortunately we haven’t been able to figure out a good workaround. We tried randomly guessing what the offset was (i.e. X minutes or X seconds) but that doesn’t seem to work well since we can’t determine what the number is. This seems to have started being an issue around March of this year I believe.

@atlatin one thing I am doing for now is fetching a generous range of picks and not storing them if I already have their node_id instead of trying to guess the magic math.

Unsure if this affects you too, but I am noticing that I must fetch records using timestamps in EST (not even EDT) and the timestamps that come back are UTC. So this also caused an issue recently as daylight savings shifted recently as well.

@kokua that sounds like a good workaround, just unfortunately over my head on how to process in that manner (comparing to existing node_id and then not storing).

The EST issue you mentioned is the same here and caused problems for us during the shift from daylight savings until we accounted for that hour difference.

Strange that everything was fine prior to March.

I see the issues and will put this in for someone to take a look in engineering.

@Theresa I was just checking to see if any update on this so we know if we should change our setup or just wait.

We have it in the queue, but I do not have an eta.

Just checking in to see if there is any update on this?

Hello @atlatin!

I will request an update from the engineering team.

Kind regards,