At this point I think that the field being used for filtering is “shipment-date”. However, it seems that the API is brokenly doing something bizarre to the StartDate and EndDate parameters. My best guess is that they take the inputs, and then apply some timezone offset incorrectly, adding around 9 hours or something? But then after applying that broken time offset, it seems to then truncate the time entirely, rounding it off to the nearest day, but with strange rounding rules (it seems to round up sometimes, and down sometimes). Then it seems to use the StartDate and EndDate parameters with those 2 bugs applied, and filter on “shipment-date”.

This is my best guess at the moment anyway.

I generally avoid worrying about things like this by making requests whose datetimes overlap, then filtering out any results I had already received via previous requests.

bunga bunga!

I only ever use UTC for anything. Non-UTC is a pit of madness. I suppose it might be worth experimenting whether the StartDate and EndDate parameters even respect the ISO 8601 timezone at all. It’s possible MWS ignores the correct UTC “+00:00” timezone and incorrectly interprets it as some other timezone. Right now I’m waiting on support to respond regarding my new information on this bug.

Previously I was doing the overlapping hack. The scary thing about that hack is that there’s seemingly no guaranteed unique primary key in the report. So how can you be sure what is a duplicate?

Ok here’s what my investigation showed as far as how these layers of crazy bugs work:

• MWS takes the StartDate and EndDate, and ignores the timezone information (which in my case is always UTC).
• MWS then converts StartDate and EndDate to Pacific Time, on top of which they’re using Daylight Savings offsets.
• After erroneously converting to Pacific Time Daylight Savings adjusted, it then erroneously truncates the hour/time component entirely, turning it into a date time of midnight Pacific Time.
• Then it takes that midnight Pacific date time, and converts it back to UTC, and filters the “shipment-date”, which are all seemingly in UTC.

So to take a specific example of how this MWS bug functions, say you filter from 2018-02-28T08:00+00:00 to 2018-03-31T08-00+00:00. The StartDate gets converted to erroneous Pacific Time with a -8 daylight offset, so it becomes 2018-02-28T00:00. Because it’s March however, the EndDate gets a -7 daylight offset, so it becomes 2018-03-31T01:00. The UTC StartDate is then 2018-02-28T00:00 but the UTC EndDate gets rounded up to include all of 2018-03-31, so entries are returned up until 2018-03-31T23:59:59.

If the EndDate is 2018-03-31T07-00+00:00, then it becomes erroneously converted to 2018-03-31T00:00, and you lose out on getting every shipment-date in the 2018-03-31 day.

Seller support acknowledged the documentation issue and is supposedly passing it along to be fixed to say that all filtering is done on day boundaries in the Pacific Timezone. (It’s going to be pretty funny if the docs actually get updated to say that, since the behavior itself is pure insanity.)