[liususan091219]

Summary

Follow-up to #909 — closes the two loose ends from the local-time-mislabeled-as-UTC timestamp bug.

• src/slack-bridge.py:359 had the same bug fix(bridges): write task timestamps in UTC, not local time #909 fixed in the Discord/Telegram bridges — task timestamp: written as local time with a literal Z. Fixed identically with time.gmtime().
• scripts/check-utc-z-strftime.py — a new AST gate that flags single-arg time.strftime() calls whose ISO-datetime output is mislabeled as UTC. Wired as a CI step. No stock linter catches this — Ruff's DTZ rules cover datetime, not time.strftime.

Detector precision

It flags a time.strftime(<fmt>) call only when BOTH:

1. single-argument (no time tuple → always local time), AND
2. mislabeled as UTC — a literal Z in the format string, or in the enclosing f-string.

So time.strftime('%Y-%m-%dT%H:%M:%SZ', time.gmtime()) (2 args, genuine UTC) and time.strftime('%H:%M:%S') in a console log line (no UTC claim) are not flagged. Verified: before the slack-bridge fix the gate flagged exactly slack-bridge.py:359; after, it passes clean.

Test plan

• python3 scripts/check-utc-z-strftime.py — exits 1 on the buggy slack-bridge line, exits 0 after the fix
• No false positives on existing time.strftime('%H:%M:%S') console-log lines (e.g. src/github-webhook.py)
• CI: the new "UTC timestamp check" step runs and passes on this PR

Closes #916

[sonichi]

AST gate looks solid — covers both f-string-{strftime}Z and embedded-Z-in-fmt cases, excludes the 2-arg gmtime form, skips itself to avoid docstring-example false-positives. Sandboxed to time.strftime (Ruff DTZ handles datetime.strftime). slack-bridge.py:359 fix matches the established UTC pattern from PRs #909 and the in-file priors. CI integration is clean — adds scripts/** to triggers + the new step. No deps, runs on stock python3. LGTM.