If I send the following query…
… am I supposed to get consumed_at times in the eastern time zone? The request above returns times like this… “consumed_at\”:\“2018-05-01T14:51:00+00:00” — no conversion.
I am trying to determine how to convert the consumed_at times so I reliably know which date a food was consumed on. Do you convert the time and date when the user records the item into UTC? And then convert it back to the named time zone on request?
The real meat of the issue is this… when a user enters food in the Nix app, it is associated with a date and a meal. However, the date “consumed_at” seems to reflect the timestamp the user entered the information. When I try to sift through the data from the /log API, the timestamps can confuse what day something was consumed. For example, if I backfill data for 4/30 on the morning of 5/1, the data seems to be consumed_at on 5/1. Is the user’s selection for a Date and Meal available via the API?
This endpoint will will return all food objects that fall within the given date range in that timezone. However, the timestamp is still returned in UTC. Your client will need to do the timestamp conversion to the appropriate timezone.
For the example you posted above, if you backfill data for say “late snack” on 4/30, then the utc timestamp for that will be 5/1. However on the client, converting that timestamp to your needed timezone, will show the timestamp as 4/30
Thanks for the reply.
In my example, I am asking for all foods on 5/1. The parameters are begin=2018-05-01&end=2018-05-02. I do receive a list of everything recorded on 5/1, including foods that were entered at 9p, 10p and 11p EST. That’s fine and the API seems to be working properly.
However, in this case, the user entered foods for days other than 5/1. That is, in the Nix app, some of the foods entered on 5/1 were assigned to 4/30. The app shows them on the appropriate day — but the API only shows me the timestamp when the entries were made.
What I want is the date and meal the person assigned the food to.
The api does not take the created at time stamp into account when pulling the foods to return, just the consumed at timestamp as well as the timezone + date range etc.
I just ran a similar test to the one you described (logging a food to yesterdays log) and pulling the log just for today… and I was seeing the desired response (just my food log for today).
One thing I can think of is that when logging the food, you are in a different timezone than US/Eastern, say US/Pacific, or you have set your preference to a different timezone. So it is possible that when you are pulling foods for US/Eastern time, that food that was consumed on 4/40 US/Pacific time, was actually 5/1 US/Eastern time due to the 3 hour time difference.
I am not sure if that falls under your use case, but please make sure to account for this possibility.
For the meal that the food is assigned to, there is a “meal_type” attribute in the response. You can use those to determine the meal.
I did a little experiment and it looks like when you backfill, it does assign a workable time. For example, I added something to Lunch on 5/5 and it set the time to Noon EST (adjusted from UTC).
I need to dig into what our user did then… because her foods are assigned to different days, but the timestamps all put them on the same day.