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

jim_m_58 said:

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.

Yeah we already said all of that before. My point was maintaining the set of rules is possible and it's been done many times.

I also pointed out that you can maintain a condensed set of rules that is much smaller than the standard TZ database which is huge (because it has hundreds of entries, with historical data), because I've done it myself. Windows itself only has about 100 entries, and Steam Deck has about 60.

So you could have your cut-down list of "time zone + DST rules", and you could optionally also provide a way to manually specify the time zone offset / DST offset if the user needs it.

jim_m_58 said:

While LocalMoment is an option

Oh but according to you "it doesn't do what I think it does"? Already forgot you said that I guess. Par for the course where you absolutely never admit to being wrong about anything, but just quietly switch gears.

jim_m_58 said:

it seems a bit user un-friendly to have them set the lat/lon for each time they want to see

Yeah I said that too. Thanks for regurgitating points that were already made.

jim_m_58 said:

Easier to just set "UTC -5"

Yep, that was also previously discussed. Unfortunately the user will have to manually adjust their timezone offset twice a year unless they only care about places like Arizona. Maybe you have no empathy for users outside of Arizona or something.

flowstate said:

Yeah we already said all of that before. My point was maintaining the set of rules is possible and it's been done many times.

CIQ apps?  How much memory does it take?

flowstate said:

Oh but according to you "it doesn't do what I think it does"? Already forgot you said that I guess. Par for the course where you absolutely never admit to being wrong about anything, but just quietly switch gears.

You missed the post where I actually tested it and admitted I was wrong. And shows actual code for how I tested it!

Guess you missed that!

As far as LocalMoment goes, I also said you can combine the "set of rules" approach with LocalMoment.

- determine the list of "timezone + DST rules" combos you care about: e.g. Mountain Time, Mountain Time (Arizona), Eastern Time, etc.

- map the entries in the list to coordinates, and use a local moment

jim_m_58 said:

CIQ apps?  How much memory does it take?

I showed an example of a TZ string already:

"EST+5EDT,M3.2.0/2,M11.1.0/2"

If you cut your list down to maybe 30-60 entries, it's not impossible. For example, Steam Deck doesn't have a separate entry for Yukon because presumably that's not a big part of their market. In the case of a CIQ app, you could also give the user a way to set a custom time zone offset, to handle any entries missing from your list.

I already said it depends on whether you have memory to spare. You could also use individual resources to store the TZ rules data. Still consumes memory at run-time, but a smaller amount per rule.

Depending on how your app is structured (as far as memory usage goes), you could also read the time zone ruleset as one huge resource at app init time, grab your individual rules, and free the ruleset memory as soon as possible. If you can do this before you initialize the View object, you might be able to get away with having a fairly big ruleset without impacting what you can in the rest of the app.

In other words, your peak memory usage at various points could look like this:

- App init time (before view is initialized): App object + Time zone ruleset

- After view is initialized: App object + View object

Of course there's still the memory impact of the resource entries for the settings strings in the "timezone" list. Still not nearly as big as the ruleset itself.

jim_m_58 said:

You missed the post where I actually tested it and admitted I was wrong. And shows actual code for how I tested it!

Guess you missed that!

Cool thanks for that. Thanks for assuming that my first take on everything CIQ-related is wrong tho. All I had to do was read the documentation and use my brain.

It wasn't you.  When I read the API doc, it wasn't clear to me what it actually did. Only a few lines of doc, no example.  That's why I did an actual test!.

For example, based on what I saw doc it could have been you pass a time and a location and what you got back was your "local time".  So if you passed a time of 6pm and a location, you'd see it as 11a for example, which could be useful too.

Instead of having a long list, you may want to do something like this:

<setting propertyKey="@Properties.tz2" title="@Strings.tz">
    <settingConfig min="-12" max="12" type="numeric"/>
</setting>

A range of numbers.

And here, I use a boolean for the odd ones offset by 30 minutes and allow a 3 char string to ID it.

I've seen similar in other CIQ WFs I've used.

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

It doesn't matter what anyone in AZ says it is. We have standards, and the standard says AZ uses US/Arizona or America/Phoenix timezone. The people in AZ are wrong, some willfully, some because they simply do not know about the actual timezones. Most people don't know all these timezone rules, they don't even know that there is a database called the Olson DB. Take my example for midnight on May 16th or 19th in 1945. Ask any random Dutch person and they will say that 12 midnight has happened on that day. They are wrong because they don't know that part of history and the timezone change. They also probably don't know other rules that the Germans installed and never got changed after.

Point is.. we are not talking to regular Arizonians, but we are talking as developers. Developers with sources and rules that we must implement to have correctly working applications.

When an expert tells you that you are wrong, you believe the expert and don't go telling him he is wrong. It's that simple.
Example, the tides are not caused by the moon, they are caused primairly by the sun and the moon just aids a bit. And we (earth) travel through the tides. Neil deGrasse Tyson will explain it to you here: https://www.youtube.com/watch?v=dBwNadry-TU

Most people don't know that, so they use different words to explain this. But if we look at it objectively we can conclude they are wrong. Based on new information they can alter their stance and admit that they were wrong and from that moment on explain it how it actually is. That doesn't mean we want a fight, that means we have more knowledge and share it with you. It becomes a "fight" when one does not want to accept the facts and keeps denying it.

jim_m_58 said:

Instead of having a long list, you may want to do something like this:

<settingConfig min="-12" max="12" type="numeric"/>

I use a boolean for the odd ones offset by 30 minutes

allow a 3 char string to ID it.

Couple of nitpicks here:

- The "correct" range of time zone offsets is -12 to +14. (e.g. Samoa is +13)

- Some places are offset by 45 minutes, like Nepal or Eucla, Australia

- Not all timezone abbreviations are 3 characters (e.g. "AKST" = Alaska Standard Time)

It just goes to show that every solution has a certain number of issues / compromises / simplifying assumptions. Obviously you're not too worried about people who want to show the time in those places which don't match your assumptions.

Another possibility could be something like this:

- Time Zone Offset (e.g. "-5", "+3:30")
^ this would be a string and the examples could be right in the label. The downside is the input wouldn't be validated at the time the user enters the setting (within the Connect IQ or Garmin Express app).

- Time Zone Abbreviation (e.g. "EST", "EDT")

Or perhaps:

- Time Zone Offset (hours)
[integer between -12 and +14]

- Time Zone Offset (minutes)
[integer between 0 and 59]

- Time Zone Abbreviation (e.g. "EST", "EDT")

Either solution could be combined with a limited list of "TZ + DST rule combos". Like I said, the official TZ database has about 400 "timezones", but Windows only has ~100 and Steam Deck only has ~60. If a dev was willing to have 30-35 timezones (without DST rules), I don't think 60 timezones (with DST rules) is that much of a stretch, especially if you're smart about how you store and load the rules (e.g. store the rules in one big resource and load/use/free it before you instantiate the view object.)

If you use LocalMoment, then you can map "timezones" (with DST) / locations to coordinates, which use even less space than rules. (And of course the big advantage is Garmin maintains the rules for you. However, that doesn't mean you don't have to maintain the list, since new locations can be added when DST rules change. e.g. Today Colorado doesn't have a separate rule because it follows Mountain Standard Time / Mountain Daylight Time, but next year it might be on MDT all year round, which means you'd need to add a new timezone / location / rule to the list.)