Show the UTC offset in the start and done banner

[ChrisJr404]

The Start and Done banner prints the local time but nothing tells you which timezone that is, so people don't always know how it relates to the UTC times shown elsewhere (like the certificate validity dates). This adds the local UTC offset to the banner so it is obvious at a glance.

Closes #1907.

Example:

 Start 2026-08-24 17:35:20 -0400        -->> 127.0.0.1:4443 (127.0.0.1) <<--
 Done 2026-08-24 17:35:31 -0400 [  18s] -->> 127.0.0.1:4443 (127.0.0.1) <<--

I used the numeric %z offset because it is portable across GNU and BSD date and it stays correct for the half hour zones like +0530 where a "+2h" style gets messy. On a host set to UTC it shows +0000.

What is your pull request about?

• Improvement

If it's a code change please check the boxes which are applicable

• For the main program: My edits contain no tabs, indentation is five spaces and any line endings do not contain any blank chars
• I've read CONTRIBUTING.md and Coding_Convention.md
• I have tested this fix or improvement against >=2 hosts and I couldn't spot a problem

[drwetter]

Hi @ChrisJr404 ,

seems basically a good idea as #1895 refers to UTC too. However either we display everything in UTC or everything in local time (including the timezone then). Maybe with a cmd line switch.

As a step to this solution it would be great to not just add the offset but also tell it is an offset, like "$(date +%F) $(date "+%T") (UTC offset: $(date "+%z"))" --> 2026-05-06 22:19:39 (UTC offset: +0200).

I read your suggestion first different, i.e. the time shown is in UTC.

[drwetter]

PS: OpenBSD is supported too. It also understands also date "+%z"

[ChrisJr404]

Thanks for the review. I updated both banners to label the offset the way you suggested, e.g. 2026-05-06 22:19:39 (UTC offset: +0200), so it reads clearly as an offset rather than the time itself being UTC. On the broader question: I kept the local time and just annotated it with its offset, which is unambiguous and needs no new dependency. If you'd rather gate everything behind a command line switch (all-UTC vs all-local), happy to follow up, but this smaller step already resolves the ambiguity #1895 raised.

[drwetter]

That's fine to get merged, thanks.

One check failed though.

[drwetter]

@ChrisJr404 : could you amend the pattern in L82-86 in t/32_isHTML_valid.t ?

[ChrisJr404]

Amended L82-86: the Start and Done banner patterns now also match and normalize the (UTC offset: +XXXX) segment. The Done pattern in particular was breaking because the offset now sits between the timestamp and the [ Xs] scan-time, so the timestamp was no longer being masked and the two HTML runs diverged. Verified the substitutions against the real banner format.

[drwetter]

Thanks!