[WC-3536]: 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

🔶 Changes requested — one or more medium-severity items must be addressed

---

What was reviewed

File	Change
packages/pluggableWidgets/datagrid-web/CHANGELOG.md	Added [Unreleased] fix entry for date export timezone bug
packages/pluggableWidgets/datagrid-web/src/features/data-export/cell-readers.ts	Added toExcelWallClock(), parseExportDate(); routed date branches through them
packages/pluggableWidgets/datagrid-web/src/features/data-export/__tests__/cell-readers.spec.ts	New timezone handling describe block; five pre-existing tests made timezone-agnostic
packages/pluggableWidgets/datagrid-web/openspec/changes/fix-excel-export-date-timezone/	New OpenSpec change artifacts (.openspec.yaml, design.md, proposal.md, spec.md, tasks.md)

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

---

Findings

🔶 Medium — Windows CI build failure

File: CI check — Run release task on windows-latest
Problem: The Run release task on windows-latest job is failing (FAILURE), and Run release task on ubuntu-latest was cancelled as a downstream consequence. The changed files are TypeScript/spec only, so this may be a pre-existing infra flake, but it must be confirmed green (or a known-flake exemption noted) before merging.
Fix: Re-run the failed job; if it fails reproducibly, investigate the Windows-specific failure in the release task log before merging.

---

🔶 Medium — Snyk security check failure

File: CI check — security/snyk (AppDev AppStore content)
Problem: The Snyk security scan is reporting FAILURE. This PR adds no new dependencies and touches no production-facing auth/data-handling code, so it is likely a pre-existing finding, but the check must be triaged and either remediated or explicitly marked as accepted-risk before merging.
Fix: Review the Snyk findings at the linked check URL and confirm none were introduced by this PR. If pre-existing, document the accepted risk or suppress with a snyk-ignore annotation per team policy.

---

Positives

• Root-cause investigation is exceptionally rigorous: the throwaway node harness that imported the actual bundled SheetJS and compared raw XML serials (39082.958333333336 reproduced digit-for-digit) is the right tool and the design doc records it clearly.
• toExcelWallClock() is correct and minimal: re-anchoring local fields onto UTC via Date.UTC(date.getFullYear(), date.getMonth(), date.getDate(), ...) is the most legible form of the operation and the docblock explains the SheetJS contract precisely.
• parseExportDate() correctly handles the ECMAScript ambiguity: date-only ISO strings (YYYY, YYYY-MM, YYYY-MM-DD) are guarded from re-anchoring because ECMAScript already parses them as UTC, preventing a regression in negative-offset sessions that the design doc caught pre-landing.
• New tests are timezone-agnostic by construction: new Date(year, month, day) as input with new Date(Date.UTC(year, month, day)) as expected value holds under any host offset, making the 235-test run under eight timezones a meaningful cross-check rather than luck.
• The five rewritten pre-existing tests preserve all original assertion intent — no assertion was weakened, only the inputs corrected to use local construction matching what the Mendix client actually supplies.
• CHANGELOG entry is appropriately user-facing: describes the observable behavior change without leaking SheetJS implementation details.