|
|
|
|
|
|
by berkes
1028 days ago
|
|
|
> You're complaining about people encoding dates in string and at the same time you encode numbers in string. That's funny. No. I'm complaining that JSON is too limited. And that it's "type system" is lacking so much that I have to resort to hacks like encoding numbers in strings. Which I think is embarrassing for an industry. > There's standard to encode dates to string. It's called ISO-8601 and it's supported everywhere. It's not. Too many servers and services use formats other than ISO-8601. Should I call Visa that their export formats suck? Or that Random API that their JSON datefields should be changed to ISO-8601.
It's supported in most languages. But e.g. something widely used as Google Sheets doesn't support this: If you get a JSON or CSV with ISO-8601 into Google sheets, a lot of string parsing and even regexes are needed to turn it into a proper date. Saying "we use ISO-8601 and that solved everything" only works if you never need any service outside of yours and never interop or exchange data with other services. Which in practice is never for anything remotely successful. |
|
|
I have yet to see Time be easy. Anywhere. At all. From daylight savings being state-dependent, system times resetting to rand, right down to CPU monotonic timing.
Using Time handling as a criticism to JSON's architecture doesn't hold water.