There are many smart people here so maybe someone can explain the decision that the time format is the responsibility of the watchface developers.
Was it a necessity?
Is it such a core function that changing it would be a complete rewrite of the code?
I don’t have a lot of experience with the coding. Years ago I hacked a watchface that was abandoned, but I don’t recall what I did or how I did it. So please try not to get too technical.
I was just thinking ut seems logical to make it a PebbleOS setting to switch format between 12hr or 24hr.
I can’t speak for any other watchface app devs, but in my app a minute change triggers a function to redraw the graphics that are displayed on the screen. the first step in that function is to get the current time. From there I color some pixels accordingly based on how I want to display the time.
If there were a global setting for 12/24 hour preference, then my ‘draw graphics’ function will get the time. From there I color some pixels accordingly based on how I want to display the time.
In both scenarios, it is still up to the dev to decide which format to use.
Adding the setting is certainly no guarantee that it will be used.
I don’t really understand the questions and speculations in this thread. There IS a global watch setting for 12/24 hour. See Build Your Own Watchface in C // Pebble Developers clock_is_24h_style() in the SDK.
I am merely saying as a user it feels like it would be beneficial to have the ability to switch between 12hr and 24hr at the system level. Sometimes there’s a watchface that I’d like to use but it doesn’t allow me to choose the time format that I prefer.
I did notice the new app has a toggle, but as it was shared above it is the developer’s choice to implement the function.
While it is still the devs choice, it is easy for choice to use the time setting to be ‘normalized’. I had no clue the setting existed until last night, because the setting was never mentioned in any of the developer docs or examples that I saw.
to make the usage of the feature more prevalent, the feature should be added to the tutorials. If the pebble commandline tool every get the ability to define a new project as a ‘watchface’, then the feature should be added to the boilerplate output.
But those are not my choices to make, I’m just a hobby hacker.
The 12/24 format is automatically handled by the clock_copy_time_string function. If a developer isn’t using that and isn’t using clock_is_24h_style then they are the ones being nonstandard. The very first tutorial on the developer docs also covers this.
I’m not. Once I learned that my sweet Rocky watchface couldn’t be installed on my device, I checked if Alloy was available for my device in the hopes that I could port my js watchface with minimum effort. Alloy is not available either. At that point I went directly to the docs for drawing graphics using c, and ported my logic from js to c.
Not everyone is going to be using the C tutorial. Reading left to right, top to bottom, the first tutorial a new dev encounters at Tutorials // Pebble Developers is the Alloy tutorial. I’m using C because I have no other option. I started writing my watchface in JS due to having far more experience is JS than in C. I can’t be the only one.
Ah, I see. Yeah I wouldn’t expect the Alloy docs to be very complete at this point FWIW the old Rocky tutorial that Core Devices removed from their site used the phone’s locale so it’d match whatever the phone used. You’re right that the Alloy example doesn’t handle that at all.
FWIW the old Rocky tutorial that Core Devices removed from their site used the phone’s locale so it’d match whatever the phone used. You’re right that the Alloy example doesn’t handle that at all.