How should an app get the wearer's local time?

Building with UNA
1

New here, and enjoying the platform a lot. I’ve hit something I suspect is a gap rather than a mistake on my part, but I’d rather ask than assume.

std::localtime() on the watch returns UTC. The shared libc appears to have no timezone configured, so localtime() and gmtime() agree. I found this building a multi-timezone watch face: it displayed local 00:30 Sun next to LAX 17:30 Sat — exactly UTC−7, correct for the secondary zone — while the watch’s own built-in face showed the right local time. So the kernel clearly knows the offset and uses it for its own UI.

I can’t find a way for an app to obtain it:

  • SDK::Interface::ISettings — isUnitsImperial(), getHrThresholds(), getDailyGoals(), and nothing else.
  • RequestSystemSettings (0x02030000) — language, units, timeFormat, HR thresholds, daily goals, height, weight. static_asserted at 64 bytes, so nothing hiding.
  • No time or timezone message type in MessageTypes.hpp.
  • Nothing timezone-shaped in the watch’s settings.json or local_settings.json.
  • The RTC itself is UTC, not local-stored-as-UTC (otherwise the secondary zone would have rendered 7 hours off in the other direction).

Worth flagging that this affects the SDK’s own code, not just mine: SDK::Metric::MonotonicTime derives its local offset by differencing localtime() against gmtime(), which on this device silently yields zero. Anything relying on it for local-time arithmetic is quietly wrong.

Is there an intended approach I’ve missed? If not, exposing the UTC offset through ISettings (or configuring libc’s timezone so localtime() behaves as the SDK already assumes) would solve it cleanly.

Unless someone has a better idea, for now I’m planning to derive the zone from a GPS fix — nearest city from a small table, cached so it survives without a fix. That works and handles travel automatically for my use case, but it spends GPS power to recover something the device already knows, so I’d rather not if there’s a better way.

Also, a small related note: RequestSystemSettings carries the system 12/24-hour preference while ISettings doesn’t. That was a useful find — worth surfacing through ISettings too, so apps don’t duplicate a setting the user has already made and then disagree with the built-in face.

Introductions - Who are you, and what are you building with UNA?