Follow-up: I think I (spelled Claude) found the cause of 1b (post-upgrade runs missing from the chart).
taskLog.createTime is a TIMESTAMP, so with the session at +00:00 it comes back as UTC (my 9:27 PM EST run reads as 2026-11-04 02:27). But WindowedStats::dailySeries() calls toDisplayStored($value) with the default $isDatetime = true. Inside the 26-hour band, that treats the UTC value as pre-boundary America/New_York time, puts it on Nov 4, past the end of the series, and drops it.
The same applies to every chart that uses dailySeries() on a TIMESTAMP column: imaging (taskLog.createTime), storage (images.imageDateTime), inventory (inventory.iCreateDate) and fleet (hosts.hostCreateDate). Audit and snapin use DATETIME columns, so they’re fine.
Suggested fix: add an $isDatetime parameter to dailySeries(), pass it through to toDisplayStored(), and have the four TIMESTAMP callers pass false:
// WindowedStats::dailySeries(): new last parameter $countK = 'c', $isDatetime = true ) { ... $day = self::toDisplayStored( (string)$row[$dateK], $isDatetime )->format('Y-m-d'); // ImagingStats::runsPerDay(): taskLog.createTime is a TIMESTAMP return self::dailySeries($rows, $start, $end, 'd', 'c', false); // StorageStats, InventoryStats, FleetStats: same, add 'd', 'c', falseClaude put together a full patch against current dev-branch (5 files, +30/−6) if that’s helpful. I haven’t applied it to my server (yet), so it’s untested beyond reading the code. I thought I’d run it by the forum first for feedback. See attached.
Thanks
