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

Thanks for the discussion.

I'm doing basically what FlowState suggested.  I typed out about 25 different time zones.  I do the math on the offset in seconds so that I can add timezones as people request them and still get a proper display (well....I found an error last night).  I also have a widget/glance that, along with displaying Zulu time actually checks to see if you are in DST or not (https://github.com/FlyFrosty/ZuluGlance).  I'm merging the two thoughts with a current watch face (Aviation Time) and seeing if I can make a useful product (non sync'd repository: https://github.com/FlyFrosty/AviationDualTime).

It would still be nice to have a better option/more control over the settings display.  A roller (like an old digital alarm clock) would be a great option compared to a long list. Or, being able to set the hours and minutes next to each other versus the top/bottom list that you can get with grouping.

Thanks again

Be careful, as times in places in the same time zone aren't always the same (DST).

DST changes at different times based on the country or even the state in the US.

I live in the MT TZ in the US (Arizona) and Denver is  in the same TZ, but in AZ, we don't use DST, but they do in Colorado, so for 1/2 the year, times are not the same..

And DST might be used on a different date in Mexico/South America.  You can check for DST at your location, but that's not the same as for other TZ offsets or other locations,

jim_m_58 said:

Be careful, as times in places in the same time zone aren't always the same (DST).

DST changes at different times based on the country or even the state in the US.

I live in the MT TZ in the US (Arizona) and Denver is  in the same TZ, but in AZ, we don't use DST, but they do in Colorado, so for 1/2 the year, times are not the same..

And DST might be used on a different date in Mexico/South America.  You can check for DST at your location, but that's not the same as for other TZ offsets or other locations,

Amazingly, a solution for all of these problems was already covered in this thread: maintain your own (condensed) set of TZ rules. Each rule can be represented by a fairly short string such as "EST+5EDT,M3.2.0/2,M11.1.0/2" (I am not suggesting this is how it needs to be implemented in CIQ, just demonstrating how little data there is for a single TZ rule, as long as you don't care about historical changes.)

The problem of Arizona vs other locations in "Mountain Time" is easily solved by having two separate TZ rules:

- Arizona

- Mountain Time (excluding Arizona)

With CIQ System 5 devices, you can even use the new LocalMoment class and let Garmin figure it out for you, which has a ton of advantages. All you have to do is map the time zones of interest to Locations (coordinates).

jim_m_58 said:

Be careful, as times in places in the same time zone aren't always the same (DST).

You're really caught up on the literal definition of the phrase "time zone" here. Just because "Mountain Time" is the name of a "time zone", it doesn't mean your UI can't split that into two or more "logical time zones" which reflect different DST rules for the same "literal time zone".

Again:

- Arizona

- Mountain Time (excluding Arizona)

This is exactly how Windows and so many other OS's/devices implement manual time zone selection, while still supporting automatic DST adjustments.

From the TZ rule list I posted previously, the TZ rule for Arizona would be "MST7" (no DST), and the TZ rule for Mountain Time locations which do observe DST would be "MST7MDT6,M3.2.0/2,M11.1.0/2".

Yes. Garmin actually tracks this info for us and provides the current DST offset.  If it's not 0, you're using DST.

FlyFrosty said:

Yes. Garmin actually tracks this info for us and provides the current DST offset.  If it's not 0, you're using DST.

If you're referring to ClockTime.dst, last time I checked it's (incorrectly) always 0, although that could've been fixed by now. (OTOH Garmin said that they want to remove the dst field a long time ago, so it's possible that the bug will never be fixed.)

https://forums.garmin.com/developer/connect-iq/i/bug-reports/clockinfo-dst-is-0-on-the-watch-correct-value-on-the-simulator

And as pointed out, that won't help for other time zones, only your current time zone. I think you really need to either maintain your own TZ ruleset or use LocalMoment on System 5 devices.

Or just ask the user to set DST manually.

There's also the issue of users who don't fit into one of your 31 or so timezone/DST rules. Might need a "custom" timezone entry where they can just set the offset manually (and worry about DST themselves.)

e.g. I'm picturing a UI like this:

- Timezone: [list of timezone/DST rules that you care about + Custom entry]

- Custom timezone offset: [enter/select custom offset]

- Custom timezone DST: [true/false] (specifies whether DST is currently in effect for the custom timezone)

Dang.  I did not know about that error.  That sucks.

Understand when you look at that info, the sim and devices show it differently.  And again, it's only DST at your location Not for the whole timezone.

Not so much an error as the sim and real devices do it differently.  In one case, you see the DST offset value, and in the other, the offset from UTC is different.  And in both cases it's only valid for your location, not others, even in the same TZ.

In a true, self centered ego, I am only worried about me in this case (I might include others in future versions). 

So, If I get rid of the easy DTS answer and go to getDaylightSavingsTimeOffset() and math, I can get the correct answers?

Now, I'm back to 2 open projects.  Still not pleased.

FlyFrosty said:

Dang.  I did not know about that error.  That sucks.

I mean, as Jim pointed out, it wouldn't help you anyway, because different locations have different DST rules. As an extreme example, summer in the southern hemisphere happens at the same time as winter in the northern hemisphere.

To reiterate, I think your options are:

1) Let the user enable/disable DST manually, using an app setting

2) (For System 5 devices): Map each "logical timezone" (which is really a timezone/DST rule combo) to a location (coordinates), and use LocalMoment to get the local time. Under this system, "Mountain Time" (with DST) and "Arizona" (no DST), would be two separate "time zones".

I realize that Arizona doesn't literally have its own "time zone", but when you select a time zone manually in Windows (and many other modern systems), Arizona (and other locations which don't observe DST, like Saskatchewan) have their own entries.

3) Maintain your own list of timezone/DST rule definitions (like the huge list I posted previously). Again under this system, "Mountain Time" and "Arizona" would have separate entries.

If you go with 2 or 3, you would still probably want to give the user the option to disable automatic DST adjustments (and let them enable manual DST adjustments via a setting).

jim_m_58 said:

Not so much an error as the sim and real devices do it differently. 

It's an error (did you click on the link and read the bug report?) because at the time I reported the bug:

1) I'm in an Eastern time location which observes DST

During DST (in my location):

2) ClockTime.dst was 3600 in the simulator, as it should be

3) Clocktime.dst was 0 on my watch

Both my computer and my watch displayed the correct time, I had recently run outdoors with GPS fix, etc., etc.

I don't really understand why every bug has to be denied or minimized. I'm not saying it's the end of the world, it's just a known bug (at least at the time it was reported.). And it was also known that Garmin stated they would remove that field (but never did).