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

flowstate said:

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.)

The time zone stuff is determined by local laws. Since Yukon is not governed by AZ (or vice versa), the time zone settings are distinct (one can change and not the other).

dpawlyk said:

FlowState said:

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.)

The time zone stuff is determined by local laws. Since Yukon is not governed by AZ (or vice versa), the time zone settings are distinct (one can change and not the other).

Yes you are correct. I'll edit my comment to clarify the misleading text you quoted.

I will point out that *currently*, Yukon's time zone/DST rule is identical to Arizona, which explains why some systems do not offer Yukon as a distinct option, yet they do offer Arizona as a distinct option. (Also because their target market is probably more likely to live in Arizona as opposed to Yukon.)

I'll also point out that the official timezone DB has 400+ entries, many of which are (currently) duplicates of each other, and Windows only has 100 (at least my version of Windows.)

My main point stands: in Windows and other systems, what are described as "time zones" are actually combinations of time zones (in Jim's sense -- e.g. "Mountain Time" regardless of DST observance) and DST rules. And Windows (and some other systems) whittle down the list of "time zones" so it's manageable, by removing duplicates and ignoring entries that may not be frequently used.

I would argue the same strategy could be used to provide a list of "time zones" (with DST rules) in CIQ. The set of rules could be fairly compact through one of two approaches:

- don't use historical data (the full tz db is huge)

- if using System 5, map "time zones" to location coordinates and use LocalMoment, which means you're automatically using Garmin's tzmap. This is the best solution if you don't have to support old devices IMO, since you don't have to worry about updates (and you'll get whatever support Garmin has for historical data)

Is it possible to get time information directly from the user's phone?

The Fitbit had an option to query the phone directly.  This information came with everything (time, time zone...).

jm_m_58,

I tried something like your fill-ins, but did not like the way t looked/interfaced. That's what led me to ask my original question.

after few test it is looks you need only getClockTime()

dst is information but the important is timeZoneOffset it includes dst so

- A take current time and change to moment

- B add timeZoneOffset to A

- C add timeZoneOffsetFromSettings to B

show C

FlyFrosty said:

Is it possible to get time information directly from the user's phone?

The Fitbit had an option to query the phone directly.  This information came with everything (time, time zone...).

No, but I'm not 100% sure how that will help you display an alternate time zone without having the user select it somehow?

EDIT: Unless you mean that fitbit could query an alternate time zone that was set in your phone somehow (e.g. in the fitbit app). Either way, the answer is no.

To recap the feasible approaches for selecting an alternate time zone to display:

1) There's Jim's suggested method of entering the offset manually, but as you said, you didn't like the user experience

2) There's the idea of selecting just the timezone offset from a list, which works, but just like 1), won't automatically account for daylight savings time changes

3) There's the idea of having a list of "timezones + dst rules". (e.g. "Eastern Time", "Mountain Time", "Mountain Time (Arizona)", ...)

3a) If you only support new watches, you can map each entry to a location and use a LocalMoment to implicitly query Garmin's tzmap (which will automatically adjust for DST, and will automatically be maintained by Garmin to handle any rules changes).

3b) Or if you need to support older watches, you can write the rules yourself (I posted an old version of them in an early comment). But then you have to update the rules details yourself if they change.

For either of 3a) and 3b), you have to manually determine which "timezones (with DST rules)" you care about, and if rules change in the future, you may have to manually update that list (e.g. if Colorado and other Mountain Time states start observing DST all year round, but there's still Mountain Time states which observe both MST and MDT, then you'll have to add "Colorado, ..." to the list.)

Exactly what information would you want from the phone and which of the above approaches would it help with (and how)?

_psx_ said:

after few test it is looks you need only getClockTime()

dst is information but the important is timeZoneOffset it includes dst so

- A take current time and change to moment

- B add timeZoneOffset to A

- C add timeZoneOffsetFromSettings to B

show C

This is a long thread, so it's understandable if you didn't see it, but a code example for this was already posted, and OP already said that's what they're currently doing:

https://forums.garmin.com/developer/connect-iq/f/discussion/306154/what-s-the-best-way-to-handle-a-long-list-in-settings/1491151#1491151

forums.garmin.com/.../1491162