EEZ Studio Tabulator Date Values: Account for the Top-Level ISO Conversion

A Date value can arrive at EEZ Studio's Tabulator as an ISO string even when the Flow-side record contains a date object. The pinned adapter performs a conversion before passing table data onward, and that conversion scans only properties directly on each row.

The Tabulator widget reference documents the Dashboard table integration. The conversion examined here is in the tableData getter of the fixed adapter revision, EEZ Studio v0.29.0 commit 3000161d09d40a5c1dc2477ddc30b38037b3a612.

This is an input-adaptation boundary, not a general promise about the table's date formatter. A formatting rule can receive a different type from the one an application developer sees upstream.

The conversion is shallow and type-specific

The getter evaluates the Data property together with its type information and requires an array. It applies toJS, then visits each row and iterates Object.keys(row). When a directly encountered property is a Date instance, it replaces that property's value with the result of toISOString().

The loop does not recurse into nested objects. It also does not parse arbitrary date-looking strings into Date objects. A direct Date, an already encoded string and a Date nested inside another object therefore take different paths through this particular adapter step.

The source comment explains this as a compatibility workaround for the table library. The operation to rely on is the actual Date test and replacement, rather than extending that comment into a claim that all library versions lack every form of date support.

Use the same instant in three shapes

Prepare a proposed row with a direct recordedAt Date, a nested metadata.recordedAt Date and a preformatted recordedText string. Give the two Date values the same instant so that any difference is about representation and traversal depth, rather than different source timestamps.

Inspect the row at the adapter output. The direct recordedAt should have passed through toISOString. The nested Date is not visited by the shown loop, while recordedText bypasses the Date-instance condition entirely.

Observe these values before the column formatter runs. A formatter can conceal the input-type difference by rendering both values as similar text, or it can expose the difference through a failure that initially looks like a column configuration problem.

If the project's declared structure cannot express one fixture shape directly, inspect an equivalent value at the adapter boundary rather than weakening production types. The test is intended to establish what this loop transforms, not to endorse arbitrary records in the application.

Formatting and representation need separate decisions

A column that needs a human-readable date should have a defined display policy for the value it actually receives. Do not assume a direct Date object will remain available to a custom formatter merely because the original Flow record used that type.

Likewise, moving a field under a metadata object can change whether this adapter converts it. A schema refactor may therefore affect the formatter's input without changing the underlying instant. Review the adapter boundary when reorganizing records, instead of debugging only the final text.

For consistent table input, an application can normalize date-bearing fields deliberately before binding Data. That policy should state which fields are transformed and which representation each formatter accepts. It should not depend on a shallow compatibility loop accidentally reaching every timestamp in a growing schema.

Do not infer ownership from toJS alone

The presence of toJS is not, by itself, proof that every possible input graph has been deeply copied or that upstream objects can never be affected. That depends on the actual observable and plain-object values and the conversion behavior involved.

If object ownership matters, inspect the original row and nested objects before and after table adaptation in a controlled fixture. Keep that observation separate from the confirmed Date-to-string branch. This article does not claim that all inputs are mutated, or that none are.

No Dashboard or formatter was executed here. The actionable result is a small transformation map: direct Date properties are converted, nested dates are not recursively processed by this loop, and existing strings are left outside that condition. Checking that map makes a type mismatch explainable before changing column formatting or timestamp acquisition.