1.6 after upgrade: dashboard imaging chart shows 0 for all runs, and Captured times flagged UTC

[Fog_Newb]

Two related issues after upgrading from the final 1.5 dev build to 1.6.0.69, both apparently tied to the UTC storage change.

1. The dashboard “Imaging Over the last” chart shows 0 for every day

taskLog has completed runs on several days, but the chart is flat at zero. The get30day response confirms it: 0 for every date, including today.

a) Pre-upgrade runs are excluded. The fold in src/Audit/ImagingStats.php (_foldSql()) requires:

AND `logImageName` <> ''

Every taskLog row written before the upgrade has a blank logImageName (and logTaskTypeName), so all 1.5-era history is dropped:

day         logImageName  COUNT(*)
2026-10-07                4
2026-10-10                4
2026-10-12                6
2026-10-27                2
2026-10-28                2
2026-10-30                4
2026-11-03                1
2026-11-03  BigBox        5

Could the upgrade backfill logImageName from tasks/images, or could the fold fall back to the task’s image when it’s blank?

b) Post-upgrade runs are also missing. Running the fold’s SQL by hand with the same window returns today’s three runs, all named BigBox:

taskID  started
11      2026-11-03 20:52:14
12      2026-11-03 21:27:37
13      2026-11-03 22:07:13

But get30day returns [“2026-11-03”, 0]. These runs fall within 26 hours of the UTC storage boundary, and their taskLog.createTime values are in server-local time (America/New_York) rather than UTC, which may be related. In the same tasks rows, taskCreateTime is local while taskCheckIn and taskStateChangedTime are UTC.

2. New captures show UTC times with a misleading tooltip

Under Images → List All Images, captures made after the upgrade show the Captured time in UTC with an asterisk (2026-11-04 03:22:56 * for a capture that finished at 10:22 PM Eastern). The tooltip says “recorded before this server moved to UTC; written in America/New_York”. On 1.5, the same server showed local times.

From src/Base/StorageEpoch.php, I understand this is the BAND_HOURS = 26 window: values near the boundary are treated as pre-boundary and shown unadjusted. That makes sense, but for those in-band values the tooltip says they were written in America/New_York when they’re actually UTC. Wording like “recorded near this server’s move to UTC; time zone uncertain” would be more accurate.

Server time zone settings, for reference: timedatectl, FOG_TZ_INFO, PHP and MariaDB are all America/New_York. (MariaDB’s time zone tables aren’t loaded, but I see FOG deliberately avoids CONVERT_TZ().)

Version: 1.6.0.69 (Patches channel), Ubuntu 26.04 Server VM

[Fog_Newb]

Follow-up: I think 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', false

Claude 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

fog-dashboard-timestamp-fix.patch.txt

Confirmation: after midnight the chart now shows 3 runs on Nov 4, all of which actually ran on the evening of Nov 3 (8:52, 9:27 and 10:07 PM EST). So the runs weren’t lost; they were being placed a day late, off the end of the series until the window rolled over. That matches the UTC TIMESTAMP being read as pre-boundary local time in dailySeries().

TLDR;
FOG read last night run times in UTC, then mistakes them for New York time, which pushes them a day later.

[Fog_Newb]

This post is deleted!

[Fog_Newb]

This post is deleted!