php-bug-catcher / bug-catcher

94%

main: 94%

LAST BUILD ON BRANCH v2.0.2

branch: v2.0.2

CHANGE BRANCH

x

Reset

• v2.0.2
• 0.1.4
• 1.1.0
• 1.1.1
• 1.1.2
• 1.1.3
• 1.1.5
• 1.1.6
• 1.1.7
• 1.1.8
• 1.2.0
• 1.2.1
• 1.2.2
• 1.2.3
• 1.2.4
• 1.3.0
• 1.4.0
• 1.5.0
• 1.5.1
• 1.5.2
• 1.6.0
• 1.7.0
• 1.8.0
• 1.8.1
• 1.9.0
• feat/mcp-server
• fix/stacktrace-display
• main
• multi-login
• selection
• tailwind
• v2.0.0
• v2.0.0-RC1
• v2.0.0-RC2
• v2.0.0-RC3
• v2.0.0-RC4
• v2.0.1
• v2.0.3
• v2.1.0
• v2.2.0
• v2.3.0
• v2.4.0

Build # 37198303595

Build Type

push

github

Committed by tito10047

Commit Message

fix(perf): store a bucket on the server's clock, not the collector's

The collector stamps every bucket with `gmdate()`, so what arrives is UTC. The
ingest stored that instant verbatim - and every read in this bundle asks its
question in the server's own timezone, because that is the wall clock the rest
of the schema is written in: `record.date` is `new DateTimeImmutable()` and
nothing converts anything anywhere.

So on any installation not running PHP in UTC, the measurements sat an offset
away from every window that would ever look for them. On a server two hours
ahead the dashboard asked for the last hour, the buckets were two hours older
than that, and the page said there was no performance data - with the rows in
the table the whole time, the ingest answering 204, the aggregator reporting
success and nothing anywhere raising a thing.

Converting on the way in rather than at each read keeps one frame of reference
in the table: the roll-up, the retention purge, the detector and the charts all
compare like with like, and a chart axis says the time a person would have seen
on their own clock.

Two tests, because the first one alone would not have caught it: the whole
suite runs with date_default_timezone_set('UTC') from tests/bootstrap.php,
which is exactly why nothing did. One changes the clock and checks what was
stored; the other builds a window the way the dashboard builds one and insists
it finds what the collector just shipped. Asserting the stored value alone
passes with the bug still in, as long as both sides are wrong the same way.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Coverage Stats

1 of 1 new or added line in 1 file covered. (100.0%)

3132 of 3319 relevant lines covered (94.37%)

20.8 hits per line