If a WooCommerce daily report misses orders near midnight, compare the report's date field and timezone before changing the orders. An order created on one day and paid on the next can correctly appear in different daily reports. A day-only date filter also needs a defined calendar timezone.
The WooCommerce 11.2 beta advisory flags a local-day query change. As of September 23, 2026, this is pre-release guidance, not a reason to install a beta on a production store.
Name the Date You Are Actually Reporting
Write down whether the report counts creation, payment, completion, refunds, or a custom integration timestamp. Record the exact query argument, store timezone setting, date input, and whether the integration uses WooCommerce APIs or its own database query.
Pick one missing order and one order that is included. Compare their identifiers and relevant timestamps without exporting billing details. A screenshot of the order date is insufficient when the report uses the paid date. Likewise, a payment provider's settlement report can have a different business definition from your store's order report.
Do not move timestamps to make two totals agree. First establish whether both reports are intended to count the same event.
Separate the Query Paths
The day-precision query change concerns particular post-storage date queries, including paid and completed dates and product sale-date fields. It does not mean every order timestamp or every HPOS query changes in the same way. The implementation notes distinguish created and modified dates, which take another branch.
Record the active order storage mode and the path used by the failing report. If the problem appears only in the orders screen, do not assume a custom export uses that screen's filtering logic. The HPOS orders-screen query guide is useful for separating screen behavior from custom queries, not as proof that their date semantics are identical.
Build a Boundary Fixture, Not a Bigger Spreadsheet
On a staging copy, select or create synthetic records around the beginning and end of one local day. Keep other filters, such as status, constant. Your fixture should include a record just before the day, one exactly at its start, one late in the evening, and one exactly at the next day's start.
For an illustrative fixed UTC+02:00 day, local September 22 at 00:00 corresponds to September 21 at 22:00 UTC. The next local midnight corresponds to September 22 at 22:00 UTC. Those are conversion examples, not observations from your store.
Illustrative diagnostic aid. Record your own results; no customer testing is implied.
Decide which boundary records should belong to the report before executing the query. Compare returned IDs, not only the sum. Two offsetting mistakes can produce the expected total while including the wrong orders.
| Fixture |
Local time |
Expected membership for a local-day report |
| A |
Previous day, 23:59:59 |
Outside |
| B |
Selected day, 00:00:00 |
Inside |
| C |
Selected day, 23:59:59 |
Inside |
| D |
Following day, 00:00:00 |
Outside |
These expectations define your intended report contract. Confirm that the actual query operator and API support it rather than assuming every date-string syntax is equivalent.
Check Existing Offset Workarounds
Search the integration's configuration and code for manually added hours, forced UTC conversions, or a day shifted backward before querying. Document why each adjustment exists. An old workaround can become a second correction after a query implementation changes.
Test a normal day and a daylight-saving transition relevant to the store. Derive the next midnight in the store's timezone rather than assuming every local day lasts exactly 86,400 seconds. Keep the original query and its results so you can identify which change affected membership.
Close the Discrepancy With Evidence
A useful handoff lists the report definition, date field, storage mode, timezone, filter expression, and expected versus actual fixture IDs. Do not claim that an unexplained total is fixed because it happens to match today.
Keep unrelated accounting adjustments out of this technical test. If a custom report still includes the wrong records, have HandL WP trace its query path. Provide a redacted boundary fixture and the integration name so the investigation starts with the actual filtering behavior.
Sources checked September 23, 2026. Examples and diagrams are explanatory, not measurements from a customer site.