Handle short form timezone reported by some systems

[bjuppa]

Our localTimezone() function returns unexpected short form timezone names (e.g. "CET") on some systems. This breaks our tests for localTimezone as well as safeTimezone on those systems.

Seen with Deno 1.39.0 on macOS 14.2

The underlying call is Intl.DateTimeFormat()?.resolvedOptions()?.timeZone

There are no options affecting returned timeZone, so my suggestion is that we rewrite localTimezone to fallback to returning UTC whenever no / can be found in reported timeZone. The short form will not be useful for the UI anyway, for example the short forms will not be available in a dropdown.

[bjuppa]

The CET timezone is probably set by macOS in my case, this is from time settings:

[bjuppa]

I'm having second thoughts about the solution I merged yesterday that changed the return value of localTimezone(). I'm considering reverting that and changing the test instead.

The short form will not be useful for the UI anyway, for example the short forms will not be available in a dropdown.

The above ☝️ may not be true, even if a returned short form like CET is not available in a dropdown of named timezones, the dropdown would still have nothing selected just as with UTC. But... for a UI where users don't set their own timezone at all, returning CET would still be better UX than falling back to UTC!

[bjuppa]

In practice, either way won't change the experience in browsers where localTimezone() is meant to be used. Browsers generally seem to report a full named timezone in Intl.DateTimeFormat()?.resolvedOptions()?.timeZone anyway, the short form is most likely encountered in backends only.