Two tickets came in the same week.
The first: “Last Quarter is showing me 15 months of documents instead of 3.”
The second, two days later: “Today’s filter is missing an invoice I made this morning. Yesterday’s filter is showing it.”
Both bugs were in code I’d just shipped. Neither was my fault.
The plugin
The plugin is a Document Overview for a German Shopware merchant. It lists every invoice, delivery note, and credit note across thousands of orders, with read permissions per role. The accounting team opens it daily to reconcile last quarter, this month, this week. Date filters are how they find anything at all.
Bug 1: the Q1 ghost
I couldn’t reproduce ticket one.
The accounting lead clicked “Last Quarter” on her screen and saw 15 months of rows. I clicked “Last Quarter” on mine and saw 3. We were running the same code.
The thing that was different was the date. It was April for both of us, but the bug only fired when “today” landed in January, February, or March. I rolled my dev clock back to February 15. The bug appeared on the first try.
The cause was a single identifier in Shopware’s own code. The function that calculates the previous quarter’s start and end was reading the year from two different places. The start came from the quarter. The end came from today.
// Before: end date uses today's year, which jumps forward in Q1
const endDate = new Date(date.getFullYear(), startDate.getMonth() + 3, 0, 23, 59, 59);
// After: end date stays anchored to the quarter's start year
const endDate = new Date(startDate.getFullYear(), startDate.getMonth() + 3, 0, 23, 59, 59);From April through December, those two places returned the same year. The math agreed with itself. In Q1, they returned different years. The previous quarter started in October of last year, but the end date jumped to December of this year. 15 months across two calendars.
A one-character fix anchored the end to the start’s year. I sent it upstream.
Bug 2: the timezone trap
I couldn’t reproduce ticket two either.
The accounting lead’s profile had her timezone set to Europe/Berlin. Mine was UTC. Staging was UTC. The whole development setup was UTC. The accounting team in Germany worked in Berlin time.
When she clicked “today” on her filter, Shopware should have asked the database for today in Berlin. It asked for today in UTC.
Berlin runs ahead of UTC. The two days overlap, but they don’t line up. Rows from yesterday Berlin time slipped into the result. Rows from earlier this morning Berlin time were filed under tomorrow and dropped.
A team member in Los Angeles, 8 hours behind, would have lost most of a workday of invoices every time they clicked “today.”
The fix asks the database for the right calendar day in the user’s own timezone. The same fix had to extend to the timeframe presets. “Last month” for a Berlin user means the calendar month in Berlin, not the calendar month in UTC. Same goes for “last quarter” and “last year.” Days that cross daylight saving needed their own handling so a 23-hour day and a 25-hour day don’t get treated as 24.
There was a second issue tangled into the same code: every change to a filter field was firing the database query twice. The fix removed the duplicate.
Why this is bigger than two tickets
These bugs are in Shopware itself. They ship with every Shopware 6 shop on earth.
Any shop with users in non-UTC timezones, which is almost every shop, has been quietly returning skewed rows when those users filter by date. Most never noticed. The window of missing or extra rows is small enough to look like “I haven’t seen that one yet” rather than a bug.
Any shop hitting “Last Quarter” between January and March had been returning 15 months of rows for years. The accounting team I work with caught it because they live inside those filters.
Both bugs were silent until someone happened to use the filter under exactly the right conditions on exactly the right day. That is how core bugs survive in widely used software. They need a specific person doing a specific thing at a specific time, and the conditions only line up for some shops, in some quarters, in some timezones.
What I did about it
Two tracks running in parallel.
Track one: patch the client’s plugin so the accounting team had a working filter the next day. The plugin already extends Shopware’s date filter for permission rendering. Adding a local override of the broken methods on top was a few hours of work. The fix went out overnight. Their accounting team has been running a correct filter ever since.
Track two: send the same fixes back to Shopware so every other shop benefits. Three pull requests went up over the next week. Two were merged on April 27. The third is still open and being reviewed.
All three were tagged for the 6.7.10.0 release on May 6. Then 6.7.10.0 shipped without any of them.
A milestone tag in an open source project is a plan. Maintainers tag what they hope to include, then cut the release on whatever has actually been reviewed and stabilised. Merged code can sit in trunk for one or two patch releases before it actually ships in a release.
The practical read for shop owners: when a vendor or developer says “a fix is going upstream,” that fix may not reach your shop for weeks, sometimes months. If you can’t wait, the answer is a local override on top of the buggy parent. That’s what we did. The override comes off the day the upstream version finally lands.
Where this leaves you
If your team keeps getting “works on our end” from a vendor, and the bug keeps biting your accounting lead or your support staff, the cause may be in code nobody on your project wrote. Most shops live with bugs like this because nobody has time to follow them home. Someone has to.
If you run a Shopware 6 shop and this is the kind of work you want done properly, get in touch. More projects this work came from are in the case studies.
PRs on GitHub: #16380, #16439. Contributor profile at github.com/zaifastafa.
Frequently asked questions
How do I know if my Shopware shop was hit by these bugs? Two quick checks. One: do any of your admin users have a profile timezone set to anything other than UTC? If yes, their date filters have been quietly returning the wrong day, by an hour up to most of a workday depending on their zone. Two: has anyone clicked “Last Quarter” between January and March? If yes, they got 15 months of rows instead of 3. Most shops never noticed because the filter still showed something.
Should I wait for the next Shopware release or pay for a local fix? It depends on how much your team relies on date filters. If date filtering is part of a daily workflow, like accounting reconciliation, a local override is worth it. The override patches the broken methods inside your plugin, costs a day or two of developer time, and gets removed once the upstream fix lands. If filters are occasional, waiting one or two patch releases is fine. Just don’t assume a milestone tag means the next release.
Were these PRs in the Shopware 6.7.10.0 release on May 6, 2026? No. Two were merged into trunk on April 27 and tagged for 6.7.10.0. Neither shipped. The third is still open. A milestone tag is what maintainers hope to ship; the actual release contains whatever was ready in time. Merged code can sit in trunk for one or two patch releases before it ships.
When the upstream fix ships, will my local override break things? Not if the override targets the broken method by name. A clean override sits on top of Shopware’s version and wins whenever both run. Once the patch release lands, the override becomes redundant and gets removed in a single deletion. There’s no migration, no schema change, no data risk.
We’ve seen weird filter behaviour. Is it always a core bug? No, and that’s the trap. Most filter weirdness is plugin code, custom code, or a misconfigured permission. A core bug looks different: it reproduces only under specific environmental conditions, like a date or a timezone, and the same conditions reproduce it on a clean Shopware install with no plugins added. That’s the test worth running before paying anyone to chase it.
