Time zone names

‘rescue’ on-device DST processing

I'm not sure I understand here. What needs rescuing? I could be wrong but as I understand it, setDST actually works if it's called with the right info? Perhaps there is some issue with getIsDST but it looks at least like jsdGetEffectiveTimeZone is doing sensible things internally so if there is an issue the fix might be minor.

setDST might not exactly match the form you get the data on Android, but can you not convert? You mentioned not pinning day of week, but if there was somewhere that didn't do it (have we found a place?) we could update setDST in a non-breaking way by passing -1 for the day of the week.

@user140377 do you have a standalone code example (eg calling setTime,E.setDST,Data.getIsDST all together) I can run to have a look into this and debug it?

it already has 12 parameters(!), which means that unlike E.setTimeZone() it can't straightforwardly take optional time zone name parameters at the end.

I'd argue that actually that makes it trivial to add an extra argument? jswrap_espruino_setDST takes an array of args, so just if (jsvGetLength(params) == 13) { ... = jsvGetArrayItem(params,12)} would work?

Having so many arguments is a bit odd, yes, but it seems it's done such that the data can be stored in a 12 element Uint16Array which ends up being relatively efficient. Not just for Bangle.js 2 where we have bags of RAM, but for other more constrained platforms that Espruino also runs on. On many devices we have a real issue with not just RAM but the size of the binary too so having some big JSON struct to parse could really hurt there.

It also makes sense if we ever did send the data from Gadgetbridge as we would be better off sending 12 numbers than a 200 byte JSON struct.

setDST disables setTimeZone

Yes, that's what the docs say. I can see why that makes sense here to keep things backwards compatible so you can install the widget alongside Gadgetbridge? If Gadgetbridge was updated to call setDST instead, the fact that setTimeZone was ignored wouldn't matter?

widdst is relying on being the sole user of the call!

I can't think of a reason different apps should be calling setDST with different values in different places? If you were to add a setDST call to Gadgetbridge I guess we'd have to ensure users didn't have widdst installed as well or it didn't interfere, although it would still need to be available for any non-Gadgetbridge users.

So what do I think?

It seems it's fair to say you don't like the current solution - but also I think that your desire to get those 3 characters on your clock screen (which is not to everyone's taste anyway) is risking heading towards a bit of a refactoring rampage across Espruino, Gadgetbridge, the Web IDE and the App Loader, which is big enough that it could stop a non-trivial proportion of the thousands of Bangle.js users out there from having their watch tell the time properly until they update some or all software.

I really don't want to be in the position where your desire to not be told "why don't you just use this-or-that" ends up breaking possibly the most critical part of Bangle.js (telling the time) for many Bangle.js users, and I'm stuck clearing up the mess.

Of course you can do whatever you want with the code - that's the whole point - but I really don't want to merge anything back that has any risk of breaking things for existing users.

So I'd say, for this particular thing, maybe add a new time event type in the data sent to the watch from Gadgetbridge (https://www.espruino.com/Gadgetbridge#me­ssages-sent-to-bangle-js-from-phone) which we could then process on the Bangle if needed (maybe widdst could update its settings when it sees it).

At some point later we could look at removing setTime/setTimeZone but having the time event gives a good platform for experimenting (and gives your clock face something to hook onto to ensure it updates automatically as soon as the event is received), and on Bangles without the software it'll just get ignored with a warning.