• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

php-bug-catcher / bug-catcher / 37198303595
94%
main: 94%

Build:
Build:
LAST BUILD BRANCH: v2.4.0
DEFAULT BRANCH: main
Ran 04 Oct 2026 11:20AM UTC
Jobs 1
Files 145
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

04 Oct 2026 11:18AM UTC coverage: 94.366%. Remained the same
37198303595

push

github

tito10047
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>

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

Jobs
ID Job ID Ran Files Coverage
1 37198303595.1 04 Oct 2026 11:20AM UTC 145
94.37
GitHub Action Run
Source Files on build 37198303595
  • Tree
  • List 145
  • Changed 1
  • Source Changed 0
  • Coverage Changed 1
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • a8d48714 on github
  • Prev Build on main (#37188337202)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc