Hacker News Reader

Comment by nishs | Hacker News Reader

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.

View on HN

Consider the Date object harmful, use ISO strings instead, and problem solved.

So how do you manipulate ISO dates as strings?

Although 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

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.

ISO datetimes are not monotonic. That’s already one good reason not to use them for storage.

All the data comes from a JSON API and thus doesn't contain Date objects to begin with.

Makes 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.

Reply on news.ycombinator.com