Hacker News new | past | comments | ask | show | jobs | submit login

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.



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.


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?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: