sadpandajoe opened a new pull request, #44352: URL: https://github.com/apache/superset/pull/44352
### SUMMARY Fast follow to #43909, which fixed only the bare four-digit-year case of `stringifyTimeInput()` (`superset-frontend/packages/superset-ui-core/src/time-format/utils/stringifyTimeInput.ts`). Every other digit-only string was still read as an epoch offset or handed to an engine-specific `Date` parser, so it resolved to a moment near 1970 (or, for the pivot table, near 1970 even earlier — see below) and rendered wrong. This closes #43847's second reported case; the four-digit-year case was already covered by #43909. **Core parser.** `stringifyTimeInput` now only treats a digit-only string as an epoch-millisecond timestamp once it has at least 10 digits — long enough to plausibly be one. A bare four-digit string is still read as an ISO 8601 year. Any other digit-only string — a `YYYYMMDD` key like `"20260903"`, a `YYYYMM` key like `"202609"`, or a small integer like `"5"` or `"0"` — is returned unchanged rather than handed to `new Date(value)`: V8's legacy parser reads those through an implementation-specific fallback (`"202609"` becomes the year 202609, `"5"` becomes May 2001, `"0"` becomes January 2000), so leaving it to the Invalid-Date/NaN fallback doesn't hold for every length and would still silently produce a wrong date. **Pivot table.** `TableRenderers.tsx`'s `toDateFormatterInput` never reached the core fix at all: it coerced every finite numeric string to a `Number` before formatting, so a `"20260903"` pivot header rendered as `1970-01-01` independently of the core parser. Its coercion now only fires for the same 10+-digit epoch case; date keys and small integers stay strings and are handed to the (now-fixed) shared formatter to resolve. | input | before this PR | after | | --- | --- | --- | | `"20260903"` | `1970-01-01T05:37:40.903Z` | `"20260903"` (unchanged) | | `"202609"` | `Date` legacy-parses it as the year 202609 | `"202609"` (unchanged) | | `"5"` | `Date` legacy-parses it as May 2001 | `"5"` (unchanged) | | `"2017"` | `2017-01-01T00:00:00.000Z` (already fixed by #43909) | unaffected | | `"1487071353000"` | `2017-02-14T11:22:33.000Z` | unaffected | | Pivot table header `"20260903"` | rendered `1970-01-01` | rendered `20260903` unchanged | Out of scope, deliberately: epoch-*seconds* strings (e.g. a 10-digit value like `"1487071353"`) are still read as epoch milliseconds, a separate, pre-existing ambiguity noted on #43847 but not part of its reported symptoms. ### BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF N/A — not UI-visible without a running Superset instance in this environment; no screenshot was captured. ### TESTING INSTRUCTIONS ``` cd superset-frontend npx jest packages/superset-ui-core/test/time-format plugins/plugin-chart-table plugins/plugin-chart-ag-grid-table plugins/plugin-chart-pivot-table ``` By hand: put a string column of `YYYYMMDD`-style values (e.g. `20260903`) in a Table chart, set a D3 time format such as `%Y-%m-%d` on it under Customize → Customize columns; on `master` every cell renders `1970-01-01`, here the raw value is shown unchanged. For the pivot table, use the same kind of column as a row/column header with a date formatter configured — on `master` the header renders `1970-01-01`, here it renders `20260903` unchanged. ### ADDITIONAL INFORMATION - [x] Has associated issue: Fixes #43847 - [ ] Required feature flags: - [ ] Changes UI - [ ] Includes DB Migration (follow approval process in [SIP-59](https://github.com/apache/superset/issues/13351)) - [ ] Migration is atomic, supports rollback & is backwards-compatible - [ ] Confirm DB migration upgrade and downgrade tested - [ ] Runtime estimates and downtime expectations provided - [ ] Introduces new feature or API - [ ] Removes existing feature or API -- 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]
