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!

[Tom Elliott]

@Fog_Newb Thanks for the detailed report. Your diagnosis was right on all three points.

1b, runs a day late: the chart read TIMESTAMP columns as DATETIME. In the 26 hours after the move to UTC, that made a UTC time look like New York time. Your fix is in, and it covers the imaging, storage, inventory and fleet charts. This one also corrects itself once the 26 hours pass.

1a, 1.5 history missing: the upgrade added the image name column but did not fill it on old rows. A new schema step fills it from the task’s image. A run whose task or image was deleted cannot be recovered.

2, the tooltip: the asterisk on new captures is expected for the first 26 hours, and then it goes away. The tooltip wording was wrong. It now says the value “can be in America/New_York time or in UTC”.

PR: https://github.com/FOGProject/fogproject/pull/2056. It reaches the Patches channel when it merges to dev-branch. Run the schema update after you update, so the history backfill runs.