Time structure for microseconds

[rvdbreemen]

I am trying to print time based on local, also print microseconds. Something like this:
10:28:17.011352

Now with time.h and some standard C functions I can do this:

 struct tm *tod;
 gettimeofday(&now, nullptr);
 tod = localtime(&now.tv_sec);

And the print:
(int)now.tv_usec

I have looked at the API, and you have focused on TZ and seconds of time, which I get. Now my question is simple, is there any way to get a structure with microseconds in your API? Or is there a fundamental issue?

[bxparks]

Storing microseconds requires storing an extra 32-bit integer in various classes. On 8-bit AVR processors, LocalTime increases from 3 bytes to 7 bytes, LocalDateTime from 6 bytes to 10 bytes, and ZonedDateTime from 13 byte to 17 bytes. I am not aware of any Arduino clock sources with a microsecond accuracy, except maybe a GPS module. But even using a GPS module, the accuracy is limited by the sampling rate, which is apparently about 100Hz, so the accuracy is limited to 10ms. Therefore, I don't have any plans for adding support for microsecond resolution to AceTime. Why do you need this?

[rvdbreemen]

So I use the timestamps to profile code to find performance issues. On esp8266 and esp32 the system time is supporting micros(). You have supported most of time.h API, except for the microsec data structure. I get that you support many different hardware platforms and in the end, it's about the efficiency and performance of your library.

So when profiling you would want to use the time functions that are available in regular C time.h structures, which are microseconds.

Since you aim to replace the default C libraries, I actually was looking for the tm and tv strucs in your code. But your design choice is not to go that far, I can respect that. I just mean I have to fiddle around with acetime.h and time.h at the same time. When you would combine this with NTP-based time, you will be able to synchronize on the millisecond. A high CPU environment like ESP's 160MHZ or 240MHZ gives a way to have microsecond time measurements.

In the end it's not about accuracy, but about the fraction of time passed in between timestamps in code, that's all. I just want to understand the limits of your library and where I have to look to find a solution.

Thanks for answering,
Robert

[bxparks]

In my opinion, I think it helps to distinguish 2 different concepts of a "clock":

1. I'll call the first one "human clock" that provides access to the date, time, and timezone used by human beings. This is the purpose of AceTime.
2. I'll call the second one a "ticking clock" that tracks the relative passage of time, often for measurement purposes. These are provided by functions like millis(), micros() and other timers.

Some languages and environments provide a good separation of these 2 concepts (e.g. C++, Java, to some extent Python). Some environments conflate the 2 concepts more than I would like (e.g. C, Unix, Golang).

In the microcontrollers world, the term "clock" is a bit overloaded, often referring to the hardware oscillators, which is a ticking-clock. It is often not accurate enough to be a human-clock, I've seen figures like 5% inaccuracy. These hardware clocks can slow down or stop ticking when the processor goes to sleep. They can also go backwards in certain situations.

Linux provides more than 10 different clocks for different purposes. The POSIX C <time.h> API also conflates the 2 different types of clocks. I find the POSIX C API to be an impenetrable, convoluted mess, so I explicitly designed AceTime to avoid all the problems of <time.h>.

If you are doing performance measurement using micros(), then you are using a ticking-clock, and AceTime was never designed for that. You could take the interval measured by micros(), and if it's more than one second, then you can calculate the acetime_t epoch seconds, and convert this into a human-readable form. If your measurement interval is more than ~100 seconds, then I would wonder if microsecond resolution is really worth it. The link between the various ways of measuring time, the various concept of clocks, and the various APIs and libraries is the "epoch seconds", the number of seconds from a known, human-date. If you need to track this in microsecond resolution, then you need a 64-bit integer.

[rvdbreemen]

Thanks Brian for your insights. It helps me to understand your point of view and design decisions. Which make sense to me, I already use micros() and that is good enough.