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

**URL:** <https://dev.unawatch.com/t/how-should-an-app-get-the-wearers-local-time/41>\
**Category:** Building with UNA\
**Created:** [August 23, 2026, 2:17am UTC](https://dev.unawatch.com/t/how-should-an-app-get-the-wearers-local-time/41 "2026-08-23T02:17:13Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![smokey\_foss](https://avatars.discourse-cdn.com/v4/letter/s/6a8cbe/32.png) [@smokey\_foss](https://dev.unawatch.com/u/smokey_foss)\
**Post date:** [August 23, 2026, 2:17am UTC](https://dev.unawatch.com/t/how-should-an-app-get-the-wearers-local-time/41/1 "2026-08-23T02:17:13Z")

</div>

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_assert`ed 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.

---

<div class="post-metadata">

**Author:** ![shatter\_poetry](https://avatars.discourse-cdn.com/v4/letter/s/6de8d8/32.png) [@shatter\_poetry](https://dev.unawatch.com/u/shatter_poetry)\
**Post date:** [August 23, 2026, 2:30pm UTC](https://dev.unawatch.com/t/how-should-an-app-get-the-wearers-local-time/41/2 "2026-08-23T14:30:47Z")

</div>

The example apps seem to do this, e.g. [una-sdk/Examples/Apps/Alarm/Software/Libs/Sources/Service.cpp at main · UNAWatch/una-sdk · GitHub](https://github.com/UNAWatch/una-sdk/blob/main/Examples/Apps/Alarm/Software/Libs/Sources/Service.cpp#L12)

```auto
static std::tm getLocalTime()
{
    std::tm tmResult {};
    std::time_t utc = time(nullptr);

#if defined(_WIN32) || defined(_WIN64)
    localtime_s(&tmResult, &utc);
#else
    localtime_r(&utc, &tmResult);
#endif

    return tmResult;
}

```

A little bit painful, I don’t see any other SDK offering. I imagine something on the extremely long list of TO-DO

---

<div class="post-metadata">

**Author:** ![smokey\_foss](https://avatars.discourse-cdn.com/v4/letter/s/6a8cbe/32.png) [@smokey\_foss](https://dev.unawatch.com/u/smokey_foss)\
**Post date:** [August 24, 2026, 1:46am UTC](https://dev.unawatch.com/t/how-should-an-app-get-the-wearers-local-time/41/3 "2026-08-24T01:46:26Z")

</div>

Thanks for the pointer! I could not reproduce what I originally reported. My evidence was a watch face showing UTC where I expected local, and I never isolated it in a test app. Doing that today took twenty minutes and would have saved the post if I had done that before. Two explanations I can no longer tell apart: the watch may genuinely have had no timezone that evening, or the package I installed may not have been the code I thought.

One thing from the original post I think still stands, as a convenience rather than a gap: there is no way to get the offset as a plain number. `ISettings` has three getters, `RequestSystemSettings` carries none, and no message type carries a zone, so you difference the two clocks to get it. And `RequestSystemSettings` exposes the 12/24-hour preference while `ISettings` does not, which is still worth surfacing so apps do not end up disagreeing with the built-in face.

Sorry for the noise, and thanks for the correction.