It's 2026 and saving a form date keeps showing a format error—is deep copy turning Date into a string?

Conclusion first: JSON.parse(JSON.stringify(obj)) is only equivalent when the data is made entirely of types JSON supports: objects, arrays, strings, numbers, booleans, and null. Once Date, undefined, functions, Symbol, NaN, or circular references appear, it does not warn you—it silently changes values or throws outright. In 2026 project integration, a date field displaying correctly in a modal but triggering a format error on save is often not an API issue, but the wrong copy method.

Why a time field turns into a string

A JSON round trip is essentially serialization plus parsing, not a complete object clone. JSON.stringify translates values into text, and JSON.parse reads them back according to JSON syntax. JSON syntax has no time object, function, or Map, so these types are replaced or dropped during translation. The result is a new reference, but the field types are no longer the same as before.

The loss happens in two stages: during serialization, values must be expressed in JSON syntax, so anything that cannot be expressed is converted or skipped; during parsing, the text can only be restored to types JSON can express, and the prototype chain, methods, or type tags cannot be restored. The string "2026-01-01T00:00:00.000Z" and a Date are completely different things in business logic. A single type difference can send debugging in the wrong direction.

Which values change in this round trip

Based on common 2026 delivery experience, the following categories appear frequently in admin back-office, order, scheduling, and reporting projects, and are easily misjudged as backend response issues. It is advisable to write clear types for time, amount, and enum fields during API contract review instead of guessing during integration.

• Date: Becomes an ISO format string; methods such as getTime and getFullYear require converting it back to a time object first.
• undefined, functions, Symbol: When used as object properties, the entire key is dropped; when they appear in an array, they become null.
• NaN, Infinity, -Infinity: All become null; the numeric meaning is rewritten, making statistical pages prone to calculation errors.
• Map, Set, RegExp, Error: Structure is lost or becomes an empty object; the order and key-value relationships of collection data cannot be restored.
• Circular references: Throw directly during serialization; the problem often explodes only at runtime.
• Class instances: All prototype methods are lost, leaving only enumerable own properties.

A checkable comparison: choosing among several deep copy methods

In 2026, a safer approach is to use them in layers based on data complexity, rather than standardizing on one pattern across the whole project. The following comparison can serve as a starting point for internal conventions, but the actual choice still depends on the runtime environment and data shape.

• JSON round trip: Low implementation cost, suitable for pure JSON data (configuration, plain-text drafts, form data with a fixed structure); does not support Date, Map, Set, functions, or circular references. Typical range: In pure data scenarios it can be rolled out within tens of minutes, but once non-JSON types are present, follow-up debugging may stretch to hours or even days (experience range).
• structuredClone: Native structured clone; supports Date, Map, Set, ArrayBuffer, and circular references; does not support functions, Symbol, or DOM nodes, and does not preserve class prototypes. Available in mainstream 2026 browsers and newer Node runtimes; a common practice is to check support first against a runtime environment checklist. Typical range: Replacement cost is about one utility function, and regression can be completed within half a day.
• Hand-written recursive copy: Highly controllable and can handle special types according to business rules; implementation and maintenance costs are relatively high, suitable for domain objects with clear type conventions. Typical range: Initial implementation takes half a day to two days, and each additional type later requires added tests.
• Third-party utility libraries: Broad coverage and convenient, at the cost of added bundle size and ongoing upgrade maintenance; suitable when dependencies already exist or types are especially complex.

When comparing, look at six dimensions: supported type range, whether circular references are handled, whether prototypes are preserved, implementation cost, long-term maintainability, and compatibility on the target client and target runtime. For most business projects, separating "pure JSON data" and "data with time or collections" into two paths is usually easier to accept than pursuing one universal pattern.

Delivery scene: saving after picking a date says the format is wrong—check the copy method first

During integration of an admin back-office order edit modal, the list page copied the order object returned by the API into the form using a JSON round trip, and the date picker in the modal was bound to a time object. When the page opened, the date displayed correctly; after the user edited it and clicked save, the API returned "invalid time format." The constraints were clear: a tight schedule, usually needing to go live within a day or two; the API documentation only said "time" without specifying a type; and there was no comparable sample data on the asset side. A workable approach was to replace only the copy method first without touching business logic; locating and fixing it in the test environment often took around half a day. If the JSON round trip is treated as a universal deep copy and rolled out across the whole project, every later module involving time must be rechecked, and rework cost expands from half a day to several days (experience range). The copy method is part of the API contract and should not be quietly decided inside a single page.

Applicable and non-applicable boundaries: when to deep copy and when not to

Deep copy is not always safer; it is a technique with overhead. The criterion can be reduced to one sentence: Will the copy and the original data be modified at the same time, and do the two sides have different modification semantics? If yes, isolation is needed; if it is only read-only display, a direct reference actually saves more memory.

• Good for deep copy: An edit modal puts API data into a form, and the original list must not change when the user cancels; undo/redo and drafts need to keep multiple historical states.
• No need for deep copy: Read-only lists and detail views can directly reference API data; shallow copy is enough when adding or removing fields only at the first level; code that uses immutable updates already produces new objects.
• Clearly not applicable: When the data contains Date, Map, Set, circular references, or class instances, a JSON round trip is unsuitable; applying deep copy when only first-level isolation is needed only adds overhead and debugging effort.

Frequently asked questions

After JSON deep copy, undefined is lost—what if the API still needs this field?

JSON syntax has no undefined, so the key is deleted directly. Either add back a default value by field after copying, or switch to structured clone or a hand-written copy to preserve the key.

Can structuredClone be used with confidence in 2026?

In 2026, mainstream browsers and newer Node runtimes already support regular objects, arrays, Date, Map, Set, and circular references; functions and DOM nodes are still unsupported, so check against a runtime environment checklist first.

Does the spread operator {...obj} count as deep copy?

No, it only copies the first level. The second level still points to the same reference, so changing the second level of the copy also changes the original object. This is the common integration issue where "changing the copy changes the original data too."

Should API-returned data be deep copied before use?

Read-only display does not need it. Copying is recommended only when entering form editing, or when the original value must be kept for comparison or undo, and then prefer a copy method that supports time objects.

After deep copy, only the copy is changed but the original still changes—where should I look?

First confirm whether levels below the second are still sharing references, then check whether somewhere else directly modifies the original object. In most cases, the copy depth is insufficient, or two variables actually point to the same data source.

Before starting, ask one question: Does this data contain Date, undefined, Map, or circular references? If yes, do not use a JSON round trip; if no, it is indeed a lower-cost deep copy pattern for pure JSON data. If the data is only modified at the first level, shallow copy is enough, and there is no need to pay a performance cost for "safety." Applicable boundary: For cross-platform, full-stack, and amount- or time-sensitive fields, specify types in the API contract and check type consistency after copying in the acceptance checklist.