Useless Alt timezones element under Controls > Clocks?

Menu -> Clocks -> Alt. Time Zone is a dead-end on my FR955 as well. Must be a bug. Settings and changes can be made through the glances view, the same as on your FR255.

But that is not all of the silliness... When I set the watch up, about a year ago, I chose New York, Moscow, Beijing and Sydney as alternates to my own Swedish time zone. Three are correct when I write these words. The fourth is either petty political childishness (Beijing) or another proof of programming ineptitude.

Beijing (China) 8:13 (-2hr) at Swedish 10:13 summertime. That would place China about level with the United Kingdom... Correct answer, Garmin, is 16:13 since they are UTC+8.

Thanks for the confirmation about the FR955.

Menu > Clocks > Alt Time Zones works for me on my 955, and the Beijing time zone is configured properly. When I press START, I see a list of currently selected alternate time zones, as well as an Add Zone menu item.

I’m running the 20.15 beta firmware (there’s nothing in the changelog about time zones, though.)

This definitely sounds like a bug, especially since 2 people are seeing it on two different devices. I would report this to Garmin support (https://support.garmin.com/ or [email protected])

"Fixed various bugs and UI improvements" in the 20.15 Change Log would cover both bugs here ;-) So I'll let the poor people at support concentrate on the more serious cases...

When reeling from the amazement of how a watch code could bork up a Time Zone like this I finally disregarded malicious intent and landed on initialisation with Zero to avoid the dreaded NULL scenario. Then, when missing to link Beijing with +8 the default would present itself as +0 which would be UTC/GMT.

Still, why poke around in stable code to such an extent that you actually unlink a City! I distinctly remember that all of my four cities were correct a year ago, and that I set them up through the Menu -> Clocks -> Alt. Time Zone entry.

Fwiw, I'm pretty sure time zone information is updated separately from the main firmware, in order to handle legislative changes to daylight savings / summertime rules (for example). I don't open Garmin Express very often, but I have seen time zone updates when I do (with the watch connected to my PC).

soptunna said:

"Fixed various bugs and UI improvements" in the 20.15 Change Log would cover both bugs here ;-) So I'll let the poor people at support concentrate on the more serious cases...

That's assuming that the bug exists in 19.18 and not 20.15, as opposed to an alternate scenario where you and OP are seeing the same bug due to some edge case that applies to both of you, but not me.

I guess you'll find out if and when you update to 20.15 (when it goes to production.)

I added Beijing as a timezone on my FR255 and got what I think is right (+15 relative to my Pacific US time zone).

Can you delete and re-add Beijing and get the right result?

I'd imagine it was some error during a prior firmware or timezone database upgrade on the watch, where it mangled the existing entry.

You were right about deleting and re-adding the city (I even 'turned it off and on again' between the operations to widen the success chance). Now correct times all around. But I had to delete Sydney and re-add after Beijing to get them in my preferred order since a move option is lacking - and that lack has been there since I originally set it up, I remember.

However, the mangling as you call it is still hard to explain. What I imagined to be stable code obviously isn't, since they've added a graphical picker (with no search function, so you have to know a bit of geography...)

Ah, well... I know from experience that data conversion can be very tricky, so perhaps should give them a break...

soptunna said:

they've added a graphical picker (with no search function, so you have to know a bit of geography...)

Yeah this probably makes sense a lot of sense if and when you're choosing your *own* time zone (e.g. when setting up a computer or other device which doesn't have GPS built-in), but maybe not so much when you're choosing an alternate time zone.

I think it would've be nice to give the user an alternate way to select a time zone, maybe via text search. I see that on older watches, you just scrolled through a long alphabetical list (except US and Mexico zones were at the top, Baker Island was at the bottom, and Mumbai was sorted as if starts with B as in Bombay *)

(* Yes clearly at some point it used to be Bombay in some watch's UI, and when it was renamed, the sort order wasn't fixed. I'm not surprised at all)

It does seem that the new interface has far more TZ entries than the old one - one region might have a dozen entries, which means the total number of entries could be 100+,  while the old list had about 60 entries for the whole world. Probably most or all the "new" entries are just duplicates (*) with different names. (* Not to state the obvious, but a "time zone" definition in computing isn't just a UTC offset, it's also daylight savings/summer time rules.)

Maybe this is kind of thing that's really better configured using a phone.

soptunna said:

However, the mangling as you call it is still hard to explain. What I imagined to be stable code obviously isn't

But again, the time zone DB and the firmware are two separate components which can be updated independently of each other, afaik. I guess it's still possible that some firmware change caused a bug that only happened to interact with Beijing, or maybe that's just what happened in your case. Maybe it could've happened for another time zone, for someone else.

soptunna said:

Ah, well... I know from experience that data conversion can be very tricky, so perhaps should give them a break...

Yeah ime anytime a dev rolls their own code for *anything* related to time or time zones, there's a high chance of something being broken (usually some edge case that wasn't considered or that nobody cares about.)

Maybe I'm weird, but I think a list sorted by offset is easier to use than an alphabetical list or this region list.  So highlight a timezone at a time and give choices of city names from that same timezone.

6125703 said:

Maybe I'm weird, but I think a list sorted by offset is easier to use than an alphabetical list or this region list.  So highlight a timezone at a time and give choices of city names from that same timezone.

I don't think that's weird. That's how how most commercial operating systems / devices do it, when they present a list of zones (as opposed to allowing the user to type in the name of a city), like Windows and Steam Deck. That way if you know your (non-DST) offset, you can choose the same zone. Ofc this falls apart if you accidentally pick a zone with the same offset as you, but different DST rules. Then again this is still possible with the new approach. Basically the only completely foolproof method is to search for the exact city name.

One advantage of the new approach is that many more cities/regions can be listed (especially given the small screen of a Garmin watch.) Like I said, the old way had about 60 cities/regions, while the new way probably has 100+ cities/regions.

Also, one could argue that selecting a large region from a map is *almost* (but not quite) like selecting an offset. Too bad they didn't actually make it so that you graphically selected an offset while scrolling through the map.