sadpandajoe commented on code in PR #42601:
URL: https://github.com/apache/superset/pull/42601#discussion_r3685938964


##########
superset-frontend/src/utils/downloadAsPivotExcel.ts:
##########
@@ -17,12 +17,74 @@
  * under the License.
  */
 import { utils, writeFile } from 'xlsx';
+import type { WorkSheet } from 'xlsx';
+
+// ISO 8601 date (and optional time) form, e.g. "2024-01-01" or
+// "2024-01-01 00:00:00". This layout is unambiguous under any locale
+// (unlike "1/2/2024", which means different dates depending on the
+// reader), so it's safe to restore as a native Excel date.
+const ISO_DATE_RE =
+  /^(\d{4})-(\d{2})-(\d{2})(?:[ T](\d{2}):(\d{2}):(\d{2}))?$/;
+
+// `raw: true` (used below) keeps every table cell as text, so ordinary
+// numbers and dates lose their native Excel type along with the
+// locale-formatted values. A cell's text is only restored to a real number
+// or date when it is unambiguous under any locale: a plain number that
+// round-trips losslessly through Number() (e.g. "42" or "-3.5"), or an
+// ISO 8601 date/datetime string. Restoring those can't reintroduce the
+// misparsing raw: true guards against. Anything else (grouped thousands,
+// percent suffixes, trailing zero padding, other D3_FORMAT output, etc.)
+// stays as text, exactly as rendered.
+function restoreUnambiguousNumbers(sheet: WorkSheet): void {
+  Object.keys(sheet).forEach(cellRef => {
+    if (cellRef.startsWith('!')) {
+      return;
+    }
+    const cell = sheet[cellRef];
+    if (!cell || cell.t !== 's' || typeof cell.v !== 'string') {
+      return;
+    }
+    const isoMatch = cell.v.match(ISO_DATE_RE);
+    if (isoMatch) {
+      const [y, mo, d, h, mi, s] = isoMatch
+        .slice(1)
+        .map(part => Number(part ?? 0));
+      const date = new Date(y, mo - 1, d, h, mi, s);
+      // The Date constructor rolls invalid components over into the next
+      // month/day (e.g. day 40 becomes the 10th of the following month)
+      // instead of rejecting them, so confirm the parts round-trip before
+      // trusting the result.
+      const isValid =
+        date.getFullYear() === y &&
+        date.getMonth() === mo - 1 &&
+        date.getDate() === d;

Review Comment:
   Invalid time components still pass this check because only the date fields 
are round-tripped: for example, `2024-01-01 13:60:30` is silently exported as a 
native 14:00:30 cell instead of preserving the source text. Could this also 
compare the hours, minutes, and seconds, with a workbook-level regression 
assertion for the invalid-time case?



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to