Best way to model UTC time and deltas in embedded C

I'm getting ready to do some work on an embedded firmware prototype that has a GPS chip attached to it (straight C on an arm0, no OS). I'm torn on how to model UTC instants and time deltas. Traditionally in C, I'd just pick a resolution and an epoch offset and model things with "big enough" integers, but I wasn't worrying about UTC, just an internal time reference. Lately, I've been working a bunch in Swift/Kotlin/Python3, and I found myself wondering if I wouldn't be better served by building a lightweight higher order representation of instant and deltas in C. Something where I had a distinct struct for each entity, and wrote a few functions to do the math I need between them. This would require a little more time (to develop), but possibly give me a little more (type) safety. I guess I'm curious how others who have had to model UTC times in embedded C have chosen to do so. Should I go with the classic offset/epoch integer model? Or model with actual structs? (I'm not really worried about performance for this) CLARIFICATION? Lots of embedded processes have to measure time or do things at certain times. I've done a bunch of those. Some sort of rolling systick counter is your time base, and you do math against it. The only real drawback I've found over the years, is that it is possible to have bugs related to the semantic differences between a time marker (an instant that occurs on the the time counter) and a duration or delta, between two such times. Since both are (u)ints, it's easy to mix up the two with no warnings. The tricky part here is the introduction of the GPS. GPS NMEA times are in UTC field values (e.g. yymmdd, hhmmss). While the UTC gets rid of the TimeZone nightmare, it doesn't get rid of things like leap years. So at bare minimum, I have to implement the math to covert said field values into a seconds offset, and then correlate/map that with the local time counter. This lead to the question: If I have to do that anyway, why not just go all the way. My goal is to schedule things to happen at certain UTC times.

Apr 6, 2025 - 15:53

I'm getting ready to do some work on an embedded firmware prototype that has a GPS chip attached to it (straight C on an arm0, no OS).

I'm torn on how to model UTC instants and time deltas. Traditionally in C, I'd just pick a resolution and an epoch offset and model things with "big enough" integers, but I wasn't worrying about UTC, just an internal time reference.

Lately, I've been working a bunch in Swift/Kotlin/Python3, and I found myself wondering if I wouldn't be better served by building a lightweight higher order representation of instant and deltas in C. Something where I had a distinct struct for each entity, and wrote a few functions to do the math I need between them.

This would require a little more time (to develop), but possibly give me a little more (type) safety.

I guess I'm curious how others who have had to model UTC times in embedded C have chosen to do so. Should I go with the classic offset/epoch integer model? Or model with actual structs?

(I'm not really worried about performance for this)

CLARIFICATION?

Lots of embedded processes have to measure time or do things at certain times. I've done a bunch of those. Some sort of rolling systick counter is your time base, and you do math against it. The only real drawback I've found over the years, is that it is possible to have bugs related to the semantic differences between a time marker (an instant that occurs on the the time counter) and a duration or delta, between two such times. Since both are (u)ints, it's easy to mix up the two with no warnings.

The tricky part here is the introduction of the GPS. GPS NMEA times are in UTC field values (e.g. yymmdd, hhmmss). While the UTC gets rid of the TimeZone nightmare, it doesn't get rid of things like leap years. So at bare minimum, I have to implement the math to covert said field values into a seconds offset, and then correlate/map that with the local time counter. This lead to the question: If I have to do that anyway, why not just go all the way. My goal is to schedule things to happen at certain UTC times.