Thank you @Dominicbm. The timestamps conform with the other Wikimedia Analytics API standards, which as you point out, are not necessarily the most obvious.

@apaskulin Thoughts on ways we can update the docs to be more clear that requests should only use just the first day of the month? If the day is not the first of the month it is designed to fail.

Thanks again @Dominicbm!

Things we could do here include:

• Improve documentation to require YYYYMM01 dates instead of YYYYMMDD ones. [DONE]
• Improve error message from Cassandra that requires YYYYMMDD, and should require YYYYMM01 instead.
• Make the service fail fast for dates that do not match the YYYYMM01 format, this would eliminate the confusion about using i.e.: 20240124.
• Allow start and end dates to be just YYYYMM. Keeping support for YYYYMM01 format for backwards compatibility. This would require a bit more work, because of the extra testing and changing docs.

@apaskulin Thoughts on ways we can update the docs to be more clear that requests should only use just the first day of the month? If the day is not the first of the month it is designed to fail.

I think the change that @mforns made to specify YYYYMM01 in the docs is perfect. Thanks!

In T371909#10110664, @mforns wrote:

Thanks again @Dominicbm!

Things we could do here include:

• Improve documentation to require YYYYMM01 dates instead of YYYYMMDD ones. [DONE]
• Improve error message from Cassandra that requires YYYYMMDD, and should require YYYYMM01 instead.
• Make the service fail fast for dates that do not match the YYYYMM01 format, this would eliminate the confusion about using i.e.: 20240124.
• Allow start and end dates to be just YYYYMM. Keeping support for YYYYMM01 format for backwards compatibility. This would require a bit more work, because of the extra testing and changing docs.

^ I think all of the above is my preference. But I think you have to be careful with your fourth bullet, because 202501-202502 could be interpreted by most people as an inclusive range (you would get January and February), even though 20250101-20250201 is currently how you get only January.

I want to point out that this issue applies as much to the API response as to the API parameters. Maybe that is a separate task, but there are two additional points to make about the API responses:

• If you look at my second and third examples above, you see that the start and end in the context header do not reflect the actual start and end of the data provided in the response, but are just repeating what the user put in the request parameters—even when they are mid-month dates that are not the true start and end of the data in the response. This concern becomes irrelevant if you implement the suggestion in the third bullet to make make the service fail on dates that don't match the format, but right now it feels like you can produce a misleading context header.
• Also, the timestamps themselves are reflecting a false level of granularity. For clarity, in the object { "timestamp": "2024-05-01 00:00:00.000Z", "pageview-count": 208258898 }, I would like the timestamp to be for a month and not a day (or a second), which would mean actually showing 2024-05 or 202405 and not 20240501 This is more accurate to the data, and isn't dependent on how the date format is specified in the request parameter. This feels like a straightforward change, because it's just applying a normalization rule to the string that currently gets output already.