It just depends on how you are using the JSON and where it fits in an application. If I'm using a static language, it is common for me to have a TimeSpan (or similar) type and standard rules for how it can be serialized (e.g. toString, toJson, etc). In this scenario, I don't care how it is represented in JSON, I just want convenient (de)serialization.
With your example, I would need to create custom parsing logic, and handle a dynamic number of JSON fields. But if a TimeSpan class had JSON deserialization built in based on the ISO8601 format, then I wouldn't need to do anything special. That's the benefit of using the standards. Same if I wanted to convert the JSON stringified format into a postgres time span there isn't any special parsing logic I need to do.
Yes, it's just a string in JSON, so it's not semantically special. But other languages that have a TimeSpan type could take advantage of the standard serialized format.
Here is an example of what it could look like in F#, no special logic for deserializing into a custom type:
type MyEvent = {
myDuration: TimeSpan;
createdAt: DateTimeOffset;
eventId: string;
}
let rawJson =
"""
{
"myDuration":"P15DT5H0M20S",
"createdAt": "2023-08-24T20:30:00Z",
"eventId": "e_1234"
}
"""
let myEvent = JsonSerializer.Deserialize<MyEvent>(json = rawJson)
I see your point, but I guess I don't see the difference between it being structured as a string with a second deserialization step after JSON deserialization. I see the convenience of a standard way to deserialize the time stamp.
But either way you need multiple pieces of data for the duration to be correct and useful. Without the created-at time in your example the duration will be invalid in the presence of leap years/seconds.
If you want to unambiguously encode a duration of time, it needs to be in the smallest unambiguous unit that is meaningful (usually seconds/nano seconds). That will allow your duration to be correctly used without any additional logic/metadata packed along with it.
With your example, I would need to create custom parsing logic, and handle a dynamic number of JSON fields. But if a TimeSpan class had JSON deserialization built in based on the ISO8601 format, then I wouldn't need to do anything special. That's the benefit of using the standards. Same if I wanted to convert the JSON stringified format into a postgres time span there isn't any special parsing logic I need to do.
Yes, it's just a string in JSON, so it's not semantically special. But other languages that have a TimeSpan type could take advantage of the standard serialized format.
Here is an example of what it could look like in F#, no special logic for deserializing into a custom type: