I'd like to serialize a std::chrono::local_time by sending it's time_since_epoch().count() value. My question is how is a non-C++ receiver supposed to interpret that value? Is it the actual number of ticks since the epoch at local midnight (1970-01-01T00:00:00)? What about daylight saving time changes? Is the time_since_epoch() bijective with the wall clock time? That is, can there be two values of std::chrono::local_time::time_since_spoch() that represent the same wall clock/calendar time?
I cannot find detailed information about the interpretation of std::chrono::local_time::time_since_spoch() at the usual places: cppreference, the latest C++ standard draft, or Howard Hinnant's date library documentation.
'Why even serialize a std::chrono::local_time?', you may ask. Well, a use case would be a building automation system that must perform a certain task at a given local time on a special day, regardless of timezones or daylight saving time. For example, "turn off the lights at 20:00 local time on Earth Day, 2021 (April 22).
EDIT: 'Why not serialize it as an ISO8601 date/time (without any offset), you may ask?'. I want to serialize it as a compact number using a binary protocol, such as CBOR.
The value in a local_time is the exact same value it would have in a sys_time. For example:
auto lt = local_days{June/3/2021} + 18h + 30min;
lt is a local time with the indicated value. All one has to do change this to a sys_time is change local_days to sys_days:
auto st = sys_days{June/3/2021} + 18h + 30min;
I.e. one can now assert that st.time_since_epoch() == lt.time_since_epoch(). The only difference between lt and st is semantics.
So you can tell clients to consume this number as if it is Unix Time, which it can then derive year, month, day, time-of-day information, but then treat that information as a local time in (presumably) their local time zone.
In doing that "reinterpret cast", it is quite possible that the local indicated time may not exist, or may be ambiguous because there are two of them. One can up the odds of not hitting such a situation by avoiding times of day in the range 00:00:00 - 04:00:00. If one does hit this situation, there is no one right answer on how you handle it. You'll just have to state a policy along with the rest of your documentation.
...
Or maybe they just write their parser in C++20... :-)