Support for std::chrono types

[Lnk2past]

I came across this issue #2159 as I was trying to do the same for std::chrono::duration. I searched around (though admittedly not much) on whether or not it's been discussed already to directly support std::chrono types right out of the box. I figured it would be simple enough (maybe naively) to add support for this in the library, but wanted to get educated a bit more on why this may or may not be a good idea.

My initial thought is that I wouldn't want to force everyone to transitively include the chrono header, but maybe that is just a matter of making it opt-in?

[gregmarr]

That would tie all users to a particular representation, which would be a compatibility issue for anyone that is currently using the library with std::chrono::duration, and as you say adds the chrono header.

Providing it as an opt-in method that people can put in their own code base, as it is now, is IMHO the most compatible route. It could maybe be provided as a more complete example.

[Lnk2past]

Hi there, thanks for the reply! Can you elaborate on what you mean by tying people to a particular representation?

[nlohmann]

For instance, we could decide to use some ISO representation string as serialization format, whereas others may prefer using seconds as uint64_t to serialize their durations. Both may have their good arguments, and as a library, it's hard to make the "right" decision there.

[Lnk2past]

Ahh gotcha. In my project I do not require serializing values out, so I hadn't even considered what the going that way actually looks like, and even more specifically I am currently only looking at std::chrono::duration values (where I am not parsing a unit or anything, but just a raw value) and so things are much less up for interpretation. e.g. in my project I have:

namespace nlohmann
{
template <typename Rep, typename Period>
struct adl_serializer<std::chrono::duration<Rep, Period>>
{
   static void from_json(const json& j, std::chrono::duration<Rep, Period>& duration)
   {
      duration = std::chrono::duration<Rep, Period>{j.get<int64_t>()};
   }
};
}

which I use to parse things like:

{
    "time_ns": 1000,
    ...
}

to get time_ns read directly into a std::chrono::nanoseconds variable (previously I needed to read into a int64_t and then construct the std::chrono::nanoseconds which was fine but a bit clunky. Going the other way, I would have opted to forgo adding a unit since that would necessarily change the JSON value to a string. I also understand that using a raw value while the key contains the "unit" is less than ideal for a number of reasons.

I guess this is more of a philosophical question - is providing nothing better than providing some default? I understand if the answer to that question is yes. Is there no sensible default that works for "most" (I realize that "most" is impossible to measure 😃)?

[gregmarr]

I guess this is more of a philosophical question - is providing nothing better than providing some default? I understand if the answer to that question is yes. Is there no sensible default that works for "most" (I realize that "most" is impossible to measure 😃)?

Yes, it is better to provide nothing if the user can't override it, as it breaks existing programs.

Fortunately, it appears that the adl_serializer method can override the built-in to_json and from_json functions. So they could be added using direct to_json and from_json as was done for std::optional.

The question then is how to do it. Does it just record the count and assume that the user gets the period right, or does it try to record the period too, and validate it on restore?