[WC-3536][WC-3545]: Fix Data Grid 2 Excel date export writing the wrong day

[yordan-st]

Pull request type

Bug fix (non-breaking change which fixes an issue)

---

Description

Exporting a Data Grid 2 date column to Excel wrote the wrong wall clock: a value the grid renders as 1/1/2007 exported as serial 39082 — 31-Dec-2006, one full calendar day early. Before the 3.11.0/3.11.3 export work the same cell held 39082.958333 (31-Dec-2006 23:00), so users saw a stray time instead; the day shift was always present, the serial fraction merely masked which day it landed on.

Root cause is in the widget's own export path, not in the Mendix client or the date picker. SheetJS is internally inconsistent about which fields of a JS Date represent the sheet's wall clock: a raw Date through utils.aoa_to_sheet converts on the local fields, but a cell object ({ t: "d", v: Date }) defers conversion to write time, where the UTC fields are read. cell-readers.ts builds cell objects, and the Mendix client hands over a local-anchored Date, so the session's UTC offset leaked into every cell — then stripTime(), truncating on those same UTC fields, turned the stray hour into the previous day. Localize = OFF on the attribute is incidental; localized attributes were affected identically.

The fix re-anchors a date's local fields onto UTC before the cell is built, so a t: "d" cell carries exactly the wall clock the grid displays, independent of the session offset and of DST. This also fixes a second, unreported symptom found while diagnosing: time-bearing formats (dd-MMM-yyyy hh:mm) skipped stripTime() and exported the time shifted by the offset (13:35 for a 14:35 value). customContent date strings now get a zone-aware parse — strings naming a zone, and date-only ISO strings (UTC per the ECMAScript spec), are left as-is; only genuinely local-parsed strings are re-anchored.

Design and rationale: packages/pluggableWidgets/datagrid-web/openspec/changes/fix-excel-export-date-timezone/.

Scope note — WC-3536 reports three complaints, only this one needed code:

• Long-number precision: already fixed in Data Widgets 3.11.3, re-confirmed here.
• Boolean TRUE/FALSE vs the grid's Yes/No: not a defect (Excel renders a typed boolean cell as TRUE/FALSE by definition). Referred to the PM for a product decision; deliberately unimplemented in either direction.

No XML or property changes, so no mendix/docs PR is needed. Changelog entry added under [Unreleased] in datagrid-web. Export_To_Excel.js and the bundled SheetJS in @mendix/data-widgets are untouched.

Ticket: https://mendix.atlassian.net/browse/WC-3536

What should be covered while testing?

Unit suite is green 235/235 under eight timezones (Europe/Amsterdam, America/New_York, America/Anchorage, Pacific/Kiritimati +14, Pacific/Niue −11, Asia/Kathmandu +5:45, Australia/Lord_Howe +10:30 with 30-minute DST, UTC). Verified end to end against the reporter's own app on Mendix 10.24.16.

Setup: a Data Grid 2 over an entity with a Date and time attribute (test with Localize both on and off — both were affected), plus an Export to Excel button wired to the Export_To_Excel JS action. Use a session timezone with a non-zero UTC offset — the bug is invisible in UTC.

1. Date-only format, midnight values. Set the column's export type to Date with format dd-MMM-yyyy. Add rows at midnight in both DST states (e.g. 1/1/2007, 3/30/2004, 9/3/2012). Export and confirm every exported date is the same calendar day the grid shows, with no time component and no fractional serial.
2. Time-bearing format. Add a second column on the same attribute with format dd-MMM-yyyy hh:mm and a row at a non-midnight time (e.g. 14:35). Confirm the exported time matches the grid exactly and is not shifted by the session offset.
3. Non-midnight value with a date-only format. Confirm the 14:35 row exports on the correct day with the time dropped. (This case was already correct before the fix — it should stay correct.)
4. Default export type. Add a third column on the same attribute with export type Default. Confirm the exported date is on the day the grid shows.
5. Custom content column. Add a column with custom content and export type Date, exporting a date string. Check a zoneless string (2007-01-01T00:00:00), a date-only ISO string (2007-01-01), and a string with an explicit zone (2007-01-01T00:00:00Z). All three should land on 01-Jan-2007. Worth repeating in a negative-offset timezone (e.g. America/New_York), which is where the date-only ISO case is most likely to regress.
6. Negative and fractional offsets. Repeat step 1 with the session timezone set to a negative offset and to a half-hour offset (e.g. Asia/Kathmandu).
7. Regression check on the 3.11.3 work. Confirm numeric columns still export with the grid's decimals and thousands grouping, and that values over 15 significant digits still export as exact text.

[github-actions]

AI Code Review

⚠️ Approved with suggestions — low-severity items only, safe to merge

---

What was reviewed

File	Change
packages/pluggableWidgets/datagrid-web/CHANGELOG.md	Added [Unreleased] Fixed entry for the timezone export bug
packages/pluggableWidgets/datagrid-web/src/features/data-export/cell-readers.ts	Added toExcelWallClock(), parseExportDate(), re-anchoring logic for attribute and customContent date branches
packages/pluggableWidgets/datagrid-web/src/features/data-export/__tests__/cell-readers.spec.ts	Rewrote 5 pre-existing date tests to use local-constructed inputs; added new timezone handling describe block with 8 cases
packages/pluggableWidgets/datagrid-web/openspec/changes/fix-excel-export-date-timezone/	New OpenSpec artifacts (design, proposal, spec, tasks) — docs only

Skipped (out of scope): dist/, pnpm-lock.yaml, OpenSpec .openspec.yaml

---

Findings

⚠️ Low — EXPLICIT_ZONE regex does not match numeric-only offset shorthand +HHmm

File: packages/pluggableWidgets/datagrid-web/src/features/data-export/cell-readers.ts line 130
Note: The pattern /(?:Z|[+-]\d{2}:?\d{2})$/i matches +05:30 and +0530 but not +530 (single-digit-hour shorthand). ECMAScript's Date.parse accepts +0530 with the colon optional, so the regex correctly matches all forms ECMAScript produces. However +5:30 (without the leading zero) is not matched — should a user pass such a string (malformed per ISO-8601 but accepted by some runtimes) it would be incorrectly re-anchored. Not a regression from current behavior, and extremely unlikely in practice given the export-value expressions involved.

---

⚠️ Low — customContent "zoneless afternoon time" test asserts only the calendar day, not the time

File: packages/pluggableWidgets/datagrid-web/src/features/data-export/__tests__/cell-readers.spec.ts line 419–433
Note: The it.each block exports every string with a date-only format (dd-mmm-yyyy) and asserts cell.v equals new Date(Date.UTC(2007, 0, 1)). For the "zoneless afternoon time" case (2007-01-01T14:35:00) this means the time is stripped and the assertion only verifies the day. A separate test verifying that the hh:mm branch for customContent also preserves 14:35 as UTC would complement the coverage already present for the attribute path — currently only the attribute branch has an explicit time-preservation test after toExcelWallClock. Not a defect, but a coverage gap worth noting.

---

Positives

• The root cause analysis is exceptional: the SheetJS field-inconsistency was confirmed with a throwaway harness against the actual bundled artifact rather than docs or assumptions, and the discriminating signature (midnight shifts back, non-midnight lands on the correct day) was verified before touching any code.
• toExcelWallClock() carries a precise doc comment explaining which SheetJS contract it adapts to and why the naïve pass-through is wrong — exactly the kind of comment the codebase convention calls for (non-obvious invariant).
• The DST split in parseExportDate() (date-only ISO → UTC by spec, time-without-zone → local, explicit-zone → leave as-is) is the correct three-way classification and is separately tested.
• Tests are timezone-agnostic by construction (new Date(year, month, day) input vs Date.UTC(…) expectation), which is more robust than pinning process.env.TZ globally — the design decision and its rationale are documented both in the spec and in the test file's block comment.
• Pre-existing tests were rewritten rather than relaxed: inputs updated to match how the Mendix client actually supplies values, and no assertion was weakened.
• CHANGELOG entry is user-facing only, correctly describing behavior without implementation detail.