3 ms·
This fails, among other scenarios, if `someThing` includes a Date object. >>> const z = { d: new Date() } undefined >>> typeof z.d "object" >>> const
by nishs 4y ago
This fails, among other scenarios, if `someThing` includes a Date object.
>>> const z = { d: new Date() }
undefined
>>> typeof z.d
"object"
>>> const a = JSON.parse(JSON.stringify(z))
undefined
>>> typeof a.d
"string"
>>>
After the roundtrip, the property `d` is now a string, not a Date object.
- RedShift1 4y agoAll the data comes from a JSON API and thus doesn't contain Date objects to begin with.
- deleted 4y ago[deleted]
- nishs 4y agoMakes sense for the most part with these constraints then. I missed the "primitive types" portion in the original comment. The following isn't applicable for pure JSON responses, but is applicable for primitive types: An additional condition for bigint is necessary, which is a primitive type. Otherwise JSON.stringify throws: >>> const x = { i: BigInt("0x1fffffffffffff") } undefined >>> typeof x.i "bigint" >>> const b = JSON.parse(JSON.stringify(x)) Exception: TypeError: JSON.stringify cannot serialize BigInt. >>> ... and for the symbol primitive, which JSON.stringifys to undefined, and thus can't be JSON.parsed.
- sieabahlpark 4y ago[dead]
- ravenstine 4y agoConsider the Date object harmful, use ISO strings instead, and problem solved.
- eurasiantiger 4y agoSo how do you manipulate ISO dates as strings?
- ravenstine 4y agoAlthough ISO date strings can be fairly trivial to read and manipulate with RexExp or a custom parser, depending on the complexity of the task, I would recommend using something like iso-fns. https://iso-fns.org https://iso-fns.org It's too bad this library (and approach) never took off, but it's there to use nevertheless. Even without iso-fns, it's not as if mid level developer can't figure out how to write a function to perform a specific operation on an ISO date string. After over 10 years of web development, I do think this is the best known approach and is even better than storing UNIX time. Even if there were no existing libraries to help with manipulating ISO strings, I will gladly take the inconvenience in exchange for the rest of the advantages. With ISO strings, you don't get any behavioral quirks from Date; they are totally compatible with JSON; you can store the time zone along with the time; there is nothing to stop you from changing the time zone while leaving all the other values intact; ISO strings also support durations. Basically, they support most of what a software developer will be expected to do with times and dates but without any behavior or assumptions about the client time zone that introduce bugs like with Date. `<input type="datetime-local">` also uses ISO strings out of the box, which can be really convenient, and values from `<input type="date">` can be easily appended into an actual ISO string.
- deleted 4y ago[deleted]
- eurasiantiger 4y agoISO datetimes are not monotonic. That’s already one good reason not to use them for storage.