3 ms·

An often ignored part of the standards are how to represent durations (time spans). See http://xml.coverpages.org/ISO-FDIS-8601.pdf http://xml.coverpages.org/I

• duped 3y ago
  Why do you want a string format for data that can be structured? "duration": { "days": 15, "hours": 5, "seconds": 20 } Now it's not the job of your JSON parser to understand the semantics of your data. It's your input validator's - which is how it should be, imo. Note you will have to have some fallible conversion step from whatever JSON chooses to represent that data as anyway.
  • atoav 3y ago
    Because there can be benefits to having it compact and yet human readable? 2023-08-24T20:30:00Z versus "time" : { "year" : 2023, "month" : 8, "day" : 24, "hour" : 20, "minute" : 30, "second" : 0, "timezone" : "UTC", } Call me lazy, but tryping the latter took me 20 times longer. I totally would use it for internal state, but I would not store it like that or expose that to users ever.
    • duped 3y ago
      But you're talking about JSON, not a concise string that is exposed to users, and not a data format optimized for size. If you want more than a basic type you give it structure - and durations are not trivial types nor common enough to deserve their own representation. Durations optimized for storage without ambiguity would be the tuple (u64, u32, u8) where the first value is seconds, second value is nanoseconds (if precision is needed) and final value is epoch. Durations displayed to a user wouldn't ever be stored so the point is kind of moot. Optimizing for "time it takes someone to write it once" is kind of dumb since it happens once while reading it happens often, and parsing even more likely.
      • mort96 3y ago
        The ISO format can be used for a lot of things which your JSON format could never be used for. ISO works great in file names, for example. And it's really nice in some circumstances (such as the file names case) that alphabetical sort is identical to chronological sort. And just... why would you spend 10x the space to represent timestamps when ISO timestamps (or, well, RFC 3339) works just fine?
  • devmunchies 3y ago
    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)
    • duped 3y ago
      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.
• teddyh 3y ago
  > ISO/FDIS 8601 (section: 5.5.4.2 Representation of time-interval by duration only, pg. 21) Alternatively, simply refer to the ABNF definition of “duration” in RFC 3339, Appendix A.