Time zone names

[TL;DR: Your idea works, Gordon, I will do your idea (plus a separate Gadgetbridge timezone service) unless the thing at the numbered points below strikes you as better.]

Ah, I hadn't understood that setDST sidesteps the 12 parameter limit. It's documented as taking an array, but when you try it, it doesn't, it takes multiple literal arguments, and I hadn't guessed that the protocol conversion could happen under the hood, so I thought the it ws a documentation error. My ignorance, sorry.

The respect in which I means that setDST might need “rescuing” (other than the parameter count limit I falsely imagined to affect it) is the behaviour of implicitly disabling setTimeZone, which is not merely weird, it means that almost any use of it is a breaking change for someone, and you are clearly very averse to breaking changes. If Gadgetbridge starts calling it, then setTimeZone stops working after disconnection for everyone, for example.

But anyway, here's another idea:

1. Give Gadgetbridge a time zone lookup service, and move the main burden to the app. This would even let people implement time zone aware alarms and calendars, for example, and would make it easier to cache your home time zone, would allow for localisation, and so on.
   
2. [optional] Have Gadgetbridge routinely send six parameters to setTimeZone (most of which the current implementation will silently ignore, giving back compatibility): setTimeZone(offset, [tzID], [nextChangeInstant, nextOffset, nexttzID]). tzID here is the official identifier, not the user-facing label, giving you a key you can send to the above lookup service. The motivation for sending a single prospective transition is so that you can tolerate a few weeks of disconnection and not miss a DST change, while minimising code and space complexity on the watch.
   
3. Have a library that patches in a more sophisticated setTimeZone that uses the extra parameters, for people who want it. Maybe migrate this to the interpreter later if it's seen as good.
   
   

I suggest this not because I'm trying to argue with you—treating time updates uniformly in Gadgetbridge is attractive—but because it's a more capable variant of something you suggested yourself earlier, and I think it avoids disabling anything or changing any behaviour without anyone's consent.

On the social side, please understand that when I said I'm not interested in other people's solutions, I wasn't trying to defend being an asshole engineer, I was trying to explain (to third parties on this thread) that telling me to make do with someone else's watch face is kind of pointless because I bought a Bangle so I could write watch faces. “Why don't you have a different hobby” is sort of a non-suggestion in a way that “why don't you propose a better/less disruptive interface” or “have you overlooked such-and-such a consideration” is not.

And don't worry, I'm perfectly aware that I can fork the world, and that the only benefit of checking things in is to benefit others, and that you have stuff to do in your own life. Otherwise you'd have had pull requests some time ago.

My plan now:

I'll move the burden onto Gadgetbridge and do the time request and the timezone service approach, unless you turn out to giving setTimeZone extra args, or you tell me otherwise. It has the downside that my faces will need to disable E.setTimeZone so they can use the service instead, but as you say, that can be seen as prototyping a future, more uniform, interface.