sadpandajoe commented on code in PR #42601:
URL: https://github.com/apache/superset/pull/42601#discussion_r3698241486
##########
superset-frontend/src/utils/downloadAsPivotExcel.ts:
##########
@@ -17,12 +17,77 @@
* 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: string | undefined) => Number(part ?? 0));
+ const date = new Date(y, mo - 1, d, h, mi, s);
Review Comment:
In positive-offset timezones, this local `Date` is serialized by SheetJS as
the previous UTC calendar day (for example, `2024-01-01` becomes `12/31/23` in
Europe/Madrid), and the current test stops before `writeFile` so it misses the
corruption. Could this construct and validate the wall-clock value in UTC and
add a real write/read regression under a non-UTC timezone?
--
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]
