raphaelsales opened a new issue, #43847: URL: https://github.com/apache/superset/issues/43847
### Bug description `stringifyTimeInput` treats **any** all-digit string as a timestamp in milliseconds, so a date value that happens to contain only digits — a year, or a `YYYYMMDD` date key — is parsed as a few seconds past the Unix epoch and formatted as 1970. https://github.com/apache/superset/blob/master/superset-frontend/packages/superset-ui-core/src/time-format/utils/stringifyTimeInput.ts ```ts if (typeof value === 'string') { const trimmed = value.trim(); const isIntegerString = /^-?\d+$/.test(trimmed); return fn(new Date(isIntegerString ? Number(trimmed) : value)); } ``` `"2017"` becomes `new Date(2017)` — 2.017 seconds after the epoch — rather than the year 2017. The regex makes no distinction between an epoch value and a digits-only date. Every time formatter goes through this function, so it affects any chart that formats such a value. **Reproduction, at the formatter API:** ```ts import { getTimeFormatter } from '@superset-ui/core'; getTimeFormatter('%Y')('2017'); // '1970' (expected '2017') getTimeFormatter('%Y-%m-%d')('20260903'); // '1970-01-01' (expected '2026-09-03') getTimeFormatter('%Y')('1487071353000'); // '2017' (correct — a real epoch value) ``` **Reproduction, in a Table chart:** 1. Use a dataset with a column whose values are digits-only dates — a year (`2017`) or a date key (`20260903`). A `VARCHAR`/`STRING` column is enough; this is a common shape for a date dimension key. 2. Add the column to a Table chart. 3. Under **Customize → Customize columns**, set a **D3 time format** on it, e.g. `%Y` or `%Y-%m-%d`. 4. Every row renders as 1970. Rendered output for the columns above, with a correctly-formatted ISO column alongside for contrast: | label | year (`%Y`) | date_key (`%Y-%m-%d`) | iso_ts (`%Y-%m-%d`) | | --- | --- | --- | --- | | row 1 | `1970` | `1970-01-01` | `2026-09-03` | | row 2 | `1970` | `1970-01-01` | `1987-02-14` | ### Expected results A digits-only value that is not a plausible epoch timestamp is either formatted according to its actual meaning, or left untouched — not silently rendered as 1970. ### Actual results It is parsed as milliseconds since the epoch, so the rendered date is off by decades and no error is surfaced. ### Screenshots/recordings _Attached below._ ### Superset version master / latest-dev ### Python version Not applicable ### Node version 18 or greater ### Browser Chrome ### Additional context Verified on `master` at `765a4ecca5`. Found while working on #34328 / #43839, which fixes a different failure in the same function — an unparseable string rendering as `NaN:NaN:NaN`. This one is separate: the value *does* parse, just into the wrong instant, so it is silent rather than visibly broken. I deliberately did not fold a fix into #43839. Narrowing the integer-string branch — by digit count or by value range — changes how epoch-in-a-string values are parsed everywhere, and that deserves its own discussion. Two directions, if maintainers have a preference: - treat a digits-only string as an epoch value only when it falls in a plausible range (e.g. at least 10 digits, i.e. seconds/milliseconds since 1970), and otherwise let `new Date(value)` handle it; - or leave parsing alone and make the ambiguity explicit in the column-level format configuration. Happy to open a PR once there is a call on which behaviour is wanted. ### Checklist - [x] I have searched Superset docs and Slack and didn't find a solution to my problem. - [x] I have searched the GitHub issue tracker and didn't find a similar bug report. - [x] I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section. -- 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]
