I understood your comment, but the WiFi setting is "Country Code", not "System Region". This won't work in North America where e.g. there are multiple time zones that sometimes cover 3+ countries.
Lastly, does your suggestion mean a user would additionally need to set a local time zone for this to work?
What if the user's time preference is UTC?
There was a discussion about this some time ago, interestingly I don't think WiFi or time were mentioned. Cool idea!
How would that work before the router is configured?
Why not eliminate the possibility of a wrong (and therefore illegal) answer - just query the user for the correct country.
From the time zone you will get the country
just like the operating systems don't ask you for additional country code
tho there are overrides in the driver for some
I have had this problem lots in old windows XP etc as CH 13 in used here
but not always enabled
you are correct, it can only help once connected
but it just starts at current default if it can't see a server yet
but you can get connected 1st then set later if to lazy to select from drop down list
but like now until an option is selected it can be the current default settings
is there a case for UTC to not be GMT and be in Greenwich UK ?
You are aware that all (computer) time, recordings and their zones displayed - comes from a calculated offset of UTC (as it is the basis of all time zones), correct?
E-mail is also timestamped in this manner
NTP is calculated in this manner
For computing purposes - International Atomic Time (scientific time) is calculated into UTC for normal civil usage (e.g. if received by a computer acting as a Stratum 1 server) - FYI, running such a Stratum 1 device is possible on your network with some software and packages available in the OpenWrt repository
Quite a few industries and professions use UTC
UTC eliminates ambiguity in many use cases
Needing reference to a time standard that doesn't use Daylight Savings
This is covered extensively in the Wikipedia article.
I think Time Zone point has veered away from the OP's WiFi Country Code topic.
Anyway, it's how others devises do to reduce the amount of setting a user has to set
and remove the need of people to have to set it at all in most cases
tho yes I agree setting the wrong zone will brake UTC like when setting the time from browser etc
UTC and Greenwich (GMT) are not the same, UTC has no daylight saving for example, for a quite major difference.
I do run the hardware clock of all my systems in UTC, why - because that's the right thing to do, let the user facing upper levels of the software stack interpret that, the hardware should only know about UTC.
Why is that important?
Think about dual-booting (anything) and daylight saving time, with 2+ OS installations each thinking they'd be in charge of (over-)'correcting' the current system time, it's a nightmare. With UTC, the hardware clock remains untouched, each OS does its own interpretation of it at runtime and the time remains correct, always. (Even Windows can do that, even though that ability isn't visibly exposed to the user and need registry changes; UEFI itself is the most stupid contender here).
I often need to test-boot (linux-) live systems on the bare iron (x86_64), I really don't want that to mess up my system time.
…but your networking hardware won't dual-boot, you might say. Correct, but do I expect timely timezone updates for embedded devices (things like DST do change, regularly, in some part of the world more often than in others - and around here, DST is supposed to be dropped, so change is on the horizon, even if the final push remains missing). Many things depend on a correct system time, which should be as unobtrusive as possible.
Just to clarify, running the hardware and system clock in UTC does not mean Linux or Windows wouldn't be able to display the correct local time, that's independent of the hardware clock.
E.g. (desktop linux):
$ LANG= timedatectl
Local time: Mon 2024-10-28 22:08:59 CET
Universal time: Mon 2024-10-28 21:08:59 UTC
RTC time: Mon 2024-10-28 21:08:59
Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
$ LANG= date
Mon Oct 28 22:10:21 CET 2024
I don't agree with that statement and it's not clear what you mean. It sounds like you're describing a host and its software having mismatched zone configs. That's not recommended.
I to have dual boot windows/Linux
and have to edit the registry on Windows for the RealTimeIsUniversal setting
there maybe cases for not setting a time zone
maybe ocean going sea vessels or planes etc
it maybe when you are Netgear and are only selling in a few markets
it's easy to cater for them all
when you take into account the fringe cases
it gets out of hand and maybe is not worth doing
and with an increase in flash needed for the settings options
I'll put it down to not worth doing
The problems only start if you want to overload two orthogonal settings. Time zones don't correspond to your regulatory domain[*] or geo-location, nor to languages - inferring one from the other is doomed to fail.
[*] Let's get back to (continental-) North America as example, 4 times zones - even though Canada and Mexico do share (some of) the same timezones with the US, their regulatory requirements do differ.
To add to the examples of why one might want to have something in UTC. Especially in regards to networking equipment:
I have everything in UTC for all networking/CCTV equipment.
No daylight savings and clearly not in my local time zone.
This is so I don't have to deal with broken or non functional daylight savings time implementations. i.e. otherwise every year one would have to set the daylight savings date/week, or do a manual changeover every year.... in a bunch of (non openwrt) networking equipment.
I'm all for systems having their hardware clock set to UTC
and programs working from the UTC time
the timezone is just the visualisation for us humans
when considering these settings
I'm trying to think of the none technical people
these are the one that are less likely to notice wrong setting or not set it
most if not all these systems work on UTC but show local time for visuals
I'm still not sure why you would want the visuals time in UTC
best case would be for the web browser to make the visual adjustments "including logs"
using it's timezone
but even on the OpenWrt timezone page, you can make the UTC clock wrong
depending on the order of clicks you make between time zone, apply and sync with browser
my comments were all about the way other system simplify these settings
I'm not saying the limited timezone directly correlates to Wi-Fi reigns
like in modern OS's Linux and windows included
they include the granularity for both outcomes into the one selection menu
but it would add unwanted complexity so it's in the to hard basket
If you look at the frequency of tzdata updates in a general purpose linux (multiple times a year, often with very few days of advance warning before the changes come into effect), you'll realize that many (embedded/ networking) devices won't ever be able to follow in time. Mix in proprietary devices that won't ever get updated and you'll get a chaos (or stick to UTC).
Yes, most of those changes might not affect 'me', but they usually do affect at least a two figure amount of millions of citizens if the affected countries.
A strange game. The only winning move is not to play. How about a nice game of chess?
As someone in Australia +11 GMT and Southern Hemisphere
the amount of website expired certificates that are outdated for half a day
due to the local time of the site being a day behind me
and the daylight saving time turning off early in the year and back on later
this is broken on so many things I have to turn it off
I kinda should know, I guess
thanks for the info now I get it @slh
I think Time Zone point has veered away from the OP's WiFi Country Code topic.