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

You may just want to use something like UTC offset.

Timezone are not all the same time over the year.  Some areas change to/from DST on different dates. some places don't do DST, etc.

Consider Denver and Phoenix (even the same country!) and both in the US Mountain Time Zone.  Colorado does DST, Arizona doesn't

So for part of the year, MT is correct in both places but off by an hour the rest of the year.  While you could have a DST flag based on where you are, but that will only work in the same country.  If you are in Denver, your dates for DST aren't correct for London, and if you are in Phoenix, London doesn't do DST

Yes.  I have a couple of watches (and a widget/glance)  that displays the current Zulu time.  Iv'e received requests for the ability to set a second time, based on Zulu time.  This is a useful tool for those of us that travel long distances on a regular basis.  Most people use it to keep track of what time it is back home.  The DST is something I've previously (Fitbit watch faces) made the users do themselves.

Yes, I know its useful as I have a few with a second TZ,  That's why I'm saving a UTC offset is the way to go,

I live inAZ, so if you allow "MT" it will be wrong for me half the year of DST is used,

This is a more complex issue than a long string in settings,

You do know that for YEARS, Windows has had a "Phoenix" specific TZ, right?  I've only lived in AZ for 3 decades!

jim_m_58 said:

I live inAZ, so if you allow "MT" it will be wrong for me half the year of DST is used,

jim_m_58 said:

You do know that for YEARS, Windows has had a "Phoenix" specific TZ, right?  I've only lived in AZ for 3 decades!

Guess you're missing the point.

Uh, I just pasted a screenshot which has the Arizona-specific time zone above. If you're aware of that, why do you think it's impossible to do timezones because "Arizona is on Mountain Time, but Arizona doesn't observe DST." All the dev has to do is what both of us literally said: have separate "time zone entries" for places which don't observe DST or which switch over on different dates.

IOW, you keep saying something to the effect of "it's impossible to do time zones in Garmin because Mountain Time means something different in Arizona and outside of Arizona".

I keep saying that you just do what Windows does and offer at least two choices instead of one:

- Mountain Time (with DST)

- Arizona (no DST)

I'm not sure what the problem or misunderstanding is?

IOW, you're fixated on the fact that "Mountain Time" is called "Mountain Time" regardless of whether DST is observed in whatever specific geographical location you're at. Just because that's the case, doesn't mean your app has to have a single entry for "Mountain Time".

The simple solution is to have separate "time zone" entries for those geographical locations which are exceptions to the rule, like Arizona and Yukon.

A different way of looking it at is, if it's possible to do it in Windows, Linux, MacOS and embedded linux (without support for full TZ databases; only with support for rudimentary TZ strings), why would it be impossible to do it in Garmin?

The only question is whether the effort and memory usage is worth it.

jim_m_58 said:

This is a more complex issue than a long string in settings,

It's really not complex.

What we all agree doesn't work:

A single entry: "MT"

What does work:

Two entries: "Mountain Time (-7:00)" and "Arizona (-7:00)". Or to keep it simple: "Mountain Time" and "Arizona".

Windows makes it even friendlier for users by having another entry for Yukon even though it's identical to Arizona. (Both are UTC-7 and both do not observe DST.) As dpawlyk pointed out, even though Yukon and Arizona have identical time zone and DST rules today, they're distinct locations with their own laws, so that might not be true tomorrow. It makes sense for them to have different time zone entries in that light/

I've literally done this for work on an embedded system running cut-down Linux, and my "timezone database" was a simple mapping from the same user-facing "time zone" strings that Windows uses to the standard linux TZ environment variable format. Ofc Garmin doesn't support the standard TZ string so you're free to use whatever format you want.

e.g.

My code was a mapping of about 100 entries, which roughly looked like:

(this is not meant to be 100% accurate, it's just mean for illustrative purposes)

...

"Mountain Time (UTC-7)" => "MST+7MDT,M3.2.0/2,M11.1.0/2"
"Arizona (UTC-7)" => "MST+7"
...
"Eastern Time (UTC-5)" => "EST+5EDT,M3.2.0/2,M11.1.0/2"
...

Of course the only limitation here is that historical rules aren't represented. I doubt it's worth the effort and storage space anyway.

How manyCIQ  apps like this have YOU published and supported?  Zero?

jim_m_58 said:

How many apps like this have YOU published and supported?  Zero?

Nope, I haven't done any CIQ apps with timezones. I'm not sure what your point is with this question? Working on CIQ is like 0.0001% of what I do as far as coding goes. I have a day job.

1) Arizona vs "regular" Mountain Time is not the mind-blowingly hard problem that you think it is. It's literally adding one more entry to your list of time zones. Then you do the same for all the other exceptions to the rules, exactly like Windows does

2) I literally solved this exact problem at work for an embedded system (Garmin is also an embedded system), and it wasn't hard. It was just boring because I had to translate the rules by hand from one format to another, IIRC. I also had to adapt a library which auto-detected the timezone to work my custom list (based off windows timezones) as opposed to the standard linux timezones, but that's neither here nor there.

3) Anyone can do it if I can do it

4) It's been done so many times, on so many OSs and so many systems

I could literally write the Garmin code if I wanted to and so could anyone else. It's just coding, there's nothing special about Garmin except for limitations on RAM, CPU and the API, and various quirks.