What's the best way to handle a long list in settings?

Much ado about nothing . 
And jumping from topic to topic around the goal instead of focusing on the goal.

There is no point in questioning the facts, especially those that are beyond your control.
TZ and DST is a form of contract between people so it was established in good faith for something (e.g. I should see morning when wakeup at 6am in NY or Tokyo).

We don't really know why FlyFrosty need it. He/she asked about settings but nobody knows background. So:

1. Putting so many strings for TZ/DST consumes almost all 255 strings 

2.  FlyFrosty : what do yuo want to write? World clock app? I don't think you only want to write app that have a lot of settings 

Kinda funny that you say that since you are refusing to acknowledge facts. But sure I'm here only to fight. I just happen to know the difference between an atomic clock and a radio controlled clock and NTP. 

Xoxoxo

_psx_ said:

Much ado about nothing

:/

TL;DR

- Yes this discussion is stupid and it makes me sad I'm still here tbh

- "Atomic clock" can have multiple meanings just like "time zone", and what an atomic radio-controlled clock does with a time zone list of EST, CST, MST, PST and an "auto adjust time for DST" toggle doesn't prove anything either way here

- Jim is wrong about at least one of the two following statements:

1) Windows asks you to select a "time zone" (by his preferred definition of "time zone")

2) "Arizona" and "Mountain Time" are the same "time zone"

If both of those statements were correct then the behavior of Windows should be indistinguishable if you select either "Arizona" or "Mountain Time". As we've already seen before and as we'll see below, that is not the case. It's not just there to "make it easier for the user to choose", it has an effect on the behavior which adjusts the clock for DST.

As a matter of fact:

- "Arizona" and "Mountain Time" are not the same "time zone" (based on the definition that Windows must be using)

- Windows isn't using the phrase "time zone" the same way Jim uses "time zone"

-------------------------

Here's another gif which proves that "Arizona" and "Mountain Time" have different effects in Windows. You don't have to call them "time zones" if you don't want to, but that's what Windows calls them.

Screenshots:

Note that when you select "Mountain Time", you're given the option to automatically adjust for DST or not. When you select "Arizona", that option is greyed out and set to false.

My only conclusion can be that Windows has the following rules:

- "Mountain Time" supports DST

- "Arizona" does not support DST

"Mountain Time" != "Arizona" (in Windows)

--

As far as "atomic clocks" go:

https://www.homedepot.com/p/La-Crosse-Technology-16-in-White-Dial-Brushed-Silver-Atomic-Analog-Wall-Clock-BBB85654/317203205#product-overview

• 4 major timezone locations (EST, CST, MST and PST)

• DST flipping

This allows them to provide the US with a minimal interface the maximum timezone configuration. You select your major timezone and alter it a weebit to implement the DST rules. So Arizonians will opt for no DST flipping and Navajo will opt for DST flipping when setting the timezone to MST.

I looked into this item and other similar items on Amazon.

It seems that in consumer terms, what's marketed as an "atomic clock" is actually "an atomic radio-controlled clock". You're not literally buying an atomic clock, you're buying a clock which can receive radio signals from a station that has an actual atomic clock.

I actually didn't realize Jim was talking about this kind of "atomic clock" -- my bad. See, I can admit when I'm wrong or when I misunderstand something. Then again it would've been great if he had clarified what he was talking about initially, but oh well.

This is actually a great example of how the same phrase -- "atomic clock" -- can have 2 meanings, one of which refers to the other. Same as how "time zone" has 2 meanings in this discussion.

Honestly I feel like when we start quibbling about how words are used, we're arguing in bad faith, just like Jim. Obviously in the consumer space, "atomic clock" is used one way (clock which is controlled by radio signal from station with an "atomic clock"), whereas in a technical sense, "atomic clock" is used a different way (the actual device which measures time.)

• Automatically updates for daylight saving time (on/off option)

Note this is the same kind of "DST flag" which Windows has (same wording). It enables or disables *automatic* DST adjustments.

4 major timezone locations (EST, CST, MST and PST)

We can actually do a thought experiment to make this "atomic clock" relevant to our discussion. What would you expect to happen if the manufacturers added a separate "Arizona" option to the list?

It wouldn't just be there to merely "make things easier to choose", it would have an actual effect on the behavior: if you select Arizona, then the state of the "Auto DST switch" would be ignored, and the clock would just display MST all year round, instead of switching to MDT during the summer. Why do I say that? Because that's pretty much how Windows works. And also because if I lived in Arizona and I selected "Arizona" as my "time zone" on a clock or device that has a clock, I would consider its behavior to be incorrect if it adjusted for DST, because we know that Arizona doesn't observe DST.

_psx_ said:

We don't really know why FlyFrosty need it

Reading between the lines it's so the watchface can display time in an alternate time zone where the user is not physically located.

The reason we're having this discussion is because most users would prefer their clock to be auto-adjusted for DST if possible. Nobody wants to make a manual change to their clock twice a year.

Not to go on another tangent, but how stupid is it that the consumer space equates "atomic clock" with "clock that can receive time signals from a radio station that has an atomic clock". Smh

I can see how "atomic radio-controlled clock" became "atomic clock", tho.

Oh and btw:

https://www.nist.gov/pml/time-and-frequency-division/time-distribution/radio-station-wwvb/help-wwvb-radio-controlled

Some manufacturers refer to their radio controlled clocks as "atomic clocks", which isn't really true. An atomic clock has an atomic oscillator inside (such as a cesium or rubidium oscillator). A radio controlled clock has a radio inside, which receives a signal that comes from a place where an atomic clock is located.

NIST (National Institute of Standards and Technology) must be wrong tho, especially since they're the ones who administer all the time servers.

So here's the thing:

- When Jim says "atomic clock" and he means "radio-controlled clock", he's not wrong as long as you understand he means the consumer sense and not the technical sense

- When NIST says Jim is technically wrong, they're not wrong either, because they insist on using the technical definition of "atomic clock"

- When I said "atomic clocks don't care about TZ/DST" I was talking about an atomic clock in the technical sense, not the consumer "atomic radio-controlled clock" sense

What's important is the truth of these statements is dependent on context. The context determines the meaning of "atomic clock".

Going back to time zones:

When Jim says "Windows asks you to select a time zone", he's wrong because he always uses a definition of "time zone" which says that "Arizona" and "Mountain Time" are the same. They're clearly not the same in Windows.

And when he says "Arizona" and "Mountain Time" are the same, he's wrong in the context of Windows and other software/devices that let you select Arizona and Mountain Time as different "time zones". He's right in the context of the usual non-computer meaning of "time zone", but too bad that's not really what we're talking about, especially when we talk about how computer interfaces present manual "time zone" selection to users.

The problem here is ignoring context and conflating different definitions/usages of "time zone". I still can't tell whether this is happening on purpose just to troll us.

With timezones he is wrong in all cases. Arizona has according to the ICANN/IANNA tzdatabase two timezones. One is Mountain, the other is Arizona. While Arizona is located in the mountain timezone it uses different rules and thus has a different timezone. End of story.

With atomic clocks he was just trolling, knowing exactly that we would look at an actual atomic clock while he was referencing a radio controlled clock. He was just baiting us in that sense trying to be right with the timezoning and DST options that a limited interface gives you. He even used his "have you ever operated/published" fallback.

He's wrong, he knows it and he's trolling at this point.

A simple google search of "Arizona Time Zone" will tell you that it's in the Mountain Time zone.  In most of the state, its Mountain STANDARD time all year, while in the NE corner (except the Hopi Nation), it's Mountain DAYLIGHT Time during the summer.  Both are "Mountain Time"

No matter what you see at ICANN, ask ANYONE in AZ what time zone they are in, and they will say "Mountain".  They won't say "Phoenix", as Phoenix is only a small part of the state.  I seem to be debating with people that  have never been here and just want a fight.

Again, you need to understand the context.

Here's just one example from wiki.  There are many more:

https://en.wikipedia.org/wiki/Time_in_Arizona

"Time in Arizona, as in all U.S. states, is regulated by the United States Department of Transportation^[1] as well as by state and tribal law.

All of Arizona is in the Mountain Time Zone.^[2] Since 1968, most of the state—with exceptions noted below—does not observe daylight saving time and remains on Mountain Standard Time (MST) all year. This results in most of Arizona having the same time as neighboring California each year from March to November, when locations in the Pacific Time Zone observe daylight saving time."

Here's a picture from another site if that will help:

jim_m_58 said:

No matter what you see at ICANN, ask ANYONE in AZ what time zone they are in, and they will say "Mountain". 

I can only speak for myself, but I'm not arguing against that point. I keep saying that I agree with that.

I'm arguing against this point of yours: "Arizona" and "Mountain Time" are the same in Windows (and other computer software), because they're the same in the outside world.

I keep saying that a computer time zone is different from what the average person calls a time zone (I'll call this a "literal time zone" for the rest of this comment.)

Neither definition is "wrong", but the one which is used is dependent on context. The problem here is you keep using the non-computer definition, but we are talking about computers here.

Why is a "computer time zone" different from a "literal time zone"? Because computer time zones also have information about DST rules.

jim_m_58 said:

Again, you need to understand the context.

You are the one who does not understand context. And you ignore any points which you can't address.

The point you are stubbornly refusing to understand is this: for the purposes of computer software (such as Windows), "Arizona" (no DST) and "Mountain Time" (with DST) are two separate things in a list the same software calls "time zones". If you pick the first one, you get Mountain Standard Time all year round. If you pick the second one, you get Mountain Daylight Time in the summer, and Mountain Standard Time the rest of the year.

1) You said Windows asks you for the literal time zone (with your definition that says Arizona and Mountain Time are the same). Wrong.

I am not saying that definition is wrong, it's just not the definition that Windows uses. How do I know that? Because we both agree that Arizona and Mountain Time are the same time zone (your definition).

But I already posted 2 gifs which clearly show that Windows does different things when you choose Arizona and when you choose Mountain Time.

Arizona and Mountain Time cannot be the same thing in Windows if they don't cause Windows to do the same thing with the clock.

2) You also implied that "Arizona" and "Mountain Time" are the same in Windows. Also wrong.

Same reason as above: I posted 2 gifs where Windows does one thing for "Arizona" and another thing for "Mountain Time"

If you can't address the actual nuanced arguments people are making, then you lose.

Again here are screenshots of software which have Arizona as a separate "time zone", in a list of computer "time zones".

- Why do Arizona and Saskatchewan -- places which don't observe DST and are therefore exceptions to their non-computer time zone -- have their own entries on the list, and not other places like Colorado and New York? Because you're not selecting a literal time zone, you are selecting a combination of literal time zone and DST rules.

Examples

Windows:

Here instead of a single entry for Mountain Time, Windows also has Arizona, "Chihuahua, ..." and Yukon. I wonder why that could be? Oh right, it's because those places are *exceptions to the daylight savings time rules* of Mountain Time. Arizona doesn't observe DST and Chihuahua starts/ends DST at different dates compared to other Mountain Time locations.

Instead of a single entry for Central Time, there's also Saskatchewan, Easter Island, etc. What's different about those places? Saskatchewan doesn't observe DST, unlike other places in Central Time. Easter Island observes DST, but switches over on different dates compared to other places in Central Time.

Steam Deck:

I only bring up steam deck because it's a modern product that was released in 2022. All you need to know is that it's a consumer-focused handheld gaming device.

Maybe you would prefer this presentation better. The timezone list has 3 entries for "Mountain Standard Time":

"Mountain Standard Time"

"Mountain Standard Time (Mexico)"

"Mountain Standard Time (Arizona)"

Note that I am not saying those are 3 different literal time zones, I am saying that for the purposes of computer software, they are separate entries in the time zone list and they are not all identical. If you select "Mountain Standard Time" here, you get MDT/DST in the summer, and MST the rest of the year. If you select Arizona, you get MST all year round. If you select Mexico, you get DST in the summer but the start and end dates are different than other Mountain Time locations.

If computers were really asking you to select a literal time zone (your definition), then there wouldn't be multiple entries for MST. Why stop at Mexico and Arizona? They could list Denver, Boise and Calgary, for example. They don't because those aren't exceptions to the normal DST rules for MST.

Back to the original question.  A really easy way to handle this (and is done in many CIQ apps) is to have the setting for a range of numbers (or a list setting) that allows setting the UTC offset of a location, and if needed, a boolean for things like if there is a 30 minute offset.

Much easier than maintaining a set of "rules" that can change every few months, that also consume memory.

While LocalMoment is an option, it seems a bit user un-friendly to have them set the lat/lon for each time they want to see.  Easier to just set "UTC -5"