[danfry1]

Closes #8411

Describe your changes:

Notifications are stamped with 'YYYY-MM-DD hh:mm:ss.ms', which Moment renders like this:

2026-08-19 01:34:56.3456      (for 13:34:56.789 UTC)

.ms isn't milliseconds. m and s are both format tokens, so it just repeats the minute and second — the 3456 is 34 and 56 again. Separately, hh is a 12-hour clock and there's no meridiem token next to it, so 13:34 and 01:34 render identically.

'HH:mm:ss.SSS' gives a 24-hour clock and actual milliseconds:

2026-08-19 13:34:56.789

This does change the text of notification timestamps, so flagging that rather than burying it.

The timestamp JSDoc now describes the property as an API-generated UTC value in the format the implementation actually produces, rather than an optional ISO 8601 value. NotificationAPISpec also includes deterministic regression coverage: it freezes time after noon and asserts the 24-hour timestamp shape with exactly three fractional digits, without relying on a complete hardcoded timestamp.

Found this while reading through the time code for #7393. It doesn't depend on that work and still uses Moment, so it should be fine on its own.

Testing instructions are in #8411. In short: trigger any notification, open the notification list, and compare the timestamp against the wall clock — easiest to see between 13:00 and 23:59 UTC, where the hour is wrong as well as the fractional part.

Verification

• NotificationAPISpec: 11/11 passing in Chrome Headless.
• ESLint passes for NotificationAPI.js and NotificationAPISpec.js.
• git diff --check passes.

All Submissions:

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?
• Is this a notable change that will require a special callout in the release notes? — not an API change, but it does change the text of notification timestamps, so worth a line if you call those out.

Author Checklist

• Changes address original issue?
• Tests included and/or updated with changes? — NotificationAPISpec passes (11/11), including deterministic timestamp-format regression coverage.
• Has this been smoke tested?
• Have you associated this PR with a type: label? — I don't have permission to set labels; type:bug would be right.
• Have you associated a milestone with this PR? — leaving blank.
• Testing instructions included in associated issue OR is this a dependency/testcase change?

[unlikelyzero]

Some things I observed:

1. The JSDoc on the timestamp property in NotificationAPI.js (around line 413) is inaccurate on two points. It claims ISO 8601 format, but the value produced never has a T separator or Z/offset, so it wasn't ISO 8601 before this fix and still isn't after it. Separately, the [timestamp] bracket notation in the doc implies the property is optional and caller-settable, but the code assigns it unconditionally, overwriting any value the caller passes in, unlike the severity line right above it, which does honor a caller-supplied value via ||. Since this PR is what makes the format claim demonstrably wrong, it seems worth fixing the comment here rather than leaving it stale, given it's a one-line doc change with no behavior or test risk.
2. There isn't a regression test asserting on the timestamp's format. It might be worth adding a shape assertion (e.g. matching YYYY-MM-DD HH:mm:ss.SSS) instead of relying on an exact hardcoded string, since a future move to ISO 8601 would otherwise require touching a brittle exact-match test.

[danfry1]

Thanks for catching these, @unlikelyzero — both points are addressed in 47b3b67be. The JSDoc now documents the timestamp as API-generated using the actual format, and NotificationAPISpec includes deterministic regression coverage for 24-hour time and three-digit milliseconds. The focused suite passes 11/11.