header, temperature metric or US customary

[MichaelWheeley]

What does this PR do?

uses global temperature units selection to show C or F in header but not both

Type of change

• Bug fix
• New feature
• Performance improvement
• Refactor / code cleanup
• Documentation
• Translation
• Map layer plugin

How to test

Checklist

• App loads without console errors
• Tested in Dark, Light, and Retro themes
• Responsive at different screen sizes (desktop + mobile)
• If touching server.js: caches have TTLs and size caps (we serve 2,000+ concurrent users)
• If adding an API route: includes caching and error handling
• If adding a panel: wired into Modern, Classic, and Dockable layouts
• No hardcoded colors — uses CSS variables (var(--accent-cyan), etc.)
• No .bak, .old, console.log debug lines, or test scripts included

Screenshots (if visual change)

WAS

BECOMES

OR

[ceotjoe]

I'm not sure about this. On one hand it is adjusting the metrics like we do in other areas. On the other hand it is the only reference to both metrics systems on the dashboard. PR itself is fine, it's a general UX design question. Do we want to keep reference to the other metrics system within the header? @accius @alanhargreaves

[alanhargreaves]

@MichaelWheeley indicated that the change was for consistency and I think I can live with that. I do like the idea of adding both temperatures to the mouseover display. If you could add that to this PR, I think we have a winner.

[accius]

Review — Header temperature unit

Small, clean change. Honors the user's allUnits.temp preference instead of always showing both units.

Minor suggestions (non-blocking):

1. Defensive defaulting: const allUnits = config.allUnits || {}; is good — consider making it config?.allUnits || {} in case config is ever undefined on first render (other spots in this file destructure it from props so it should be set, but the guard is cheap).

2. Reuse elsewhere: other places in the app (e.g. weather panel, dx weather) already handle this by passing allUnits down; consider a tiny formatTempC(rawC, allUnits.temp) helper in utils/ to avoid the inline ternary scattering if this pattern is repeated.

3. Loss of dual display: some users may actually prefer both. Worth confirming with the wider user base — but I think following the global unit setting is the right default.

4. Checklist — please tick the "tested in Dark/Light/Retro + mobile" boxes; this is a header change so it's quick to verify.

Approved in spirit — happy to merge once the quick test-checks are confirmed.

[MichaelWheeley]

@alanhargreaves

@MichaelWheeley indicated that the change was for consistency and I think I can live with that. I do like the idea of adding both temperatures to the mouseover display. If you could add that to this PR, I think we have a winner.

done.

[MichaelWheeley]

@accius

Minor suggestions (non-blocking):

1. Defensive defaulting: const allUnits = config.allUnits || {}; is good — consider making it config?.allUnits || {} in case config is ever undefined on first render (other spots in this file destructure it from props so it should be set, but the guard is cheap).

Noted, removed temperature formatting to utils/formatWeather.js and passed config?.allUnits

2. Reuse elsewhere: other places in the app (e.g. weather panel, dx weather) already handle this by passing allUnits down; consider a tiny formatTempC(rawC, allUnits.temp) helper in utils/ to avoid the inline ternary scattering if this pattern is repeated.

Done with addtional exported formatters, please review.

3. Loss of dual display: some users may actually prefer both. Worth confirming with the wider user base — but I think following the global unit setting is the right default.

Per separate discussion added dual temperature to the mouse-over.

4. Checklist — please tick the "tested in Dark/Light/Retro + mobile" boxes; this is a header change so it's quick to verify.

Checked and done!