fix(sqllab): normalize changedOn timestamp

[villebro]

SUMMARY

#24422 introduced a regression which caused SQL Lab results to not show up in SQL Lab for clients that had a negative TZ offset. This was due to the backend returning timestamps in naive format that don't include a prefix to indicate that the timestamp is in UTC TZ. Due to parsing this using Date.parse() in the frontend, this timestamp was assumed to be in local timezone, causing an inconsistency when requesting updated queries using the epoch representation.

This fixes the issue by using the normalizeTimestamp function from @superset-ui/core, and adds tests to ensure that queriesLastUpdate in Redux state is correctly normalized (a denormalizeTimestamp util is added as it's needed for updating the tests). This new test would previously have failed on master branch when run in non-UTC TZ.

BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS

ADDITIONAL INFORMATION

• Has associated issue: fixes SQL Lab UI does not populate results - query/updated_since endpoint unexpectedly returns empty array #24487
• Required feature flags:
• Changes UI
• Includes DB Migration (follow approval process in SIP-59)
  • 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

[codecov]

Codecov Report

Merging #24513 (ead228a) into master (ba3bdc0) will increase coverage by 0.01%.
The diff coverage is 100.00%.

❗ Current head ead228a differs from pull request most recent head ccf3960. Consider uploading reports for the commit ccf3960 to get more accurate results

@@            Coverage Diff             @@
##           master   #24513      +/-   ##
==========================================
+ Coverage   69.06%   69.07%   +0.01%     
==========================================
  Files        1901     1902       +1     
  Lines       74019    74024       +5     
  Branches     8116     8117       +1     
==========================================
+ Hits        51121    51134      +13     
+ Misses      20787    20779       -8     
  Partials     2111     2111              

Flag	Coverage Δ
javascript	55.74% <100.00%> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
superset-frontend/src/SqlLab/fixtures.ts	100.00% <ø> (ø)
...core/src/time-format/utils/denormalizeTimestamp.ts	100.00% <100.00%> (ø)
...i-core/src/time-format/utils/normalizeTimestamp.ts	100.00% <100.00%> (ø)
superset-frontend/src/SqlLab/reducers/sqlLab.js	48.25% <100.00%> (+4.98%)	⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[hughhhh]

LGTM

[john-bodley]

@villebro could you expand on what you mean by,

... backend returning timestamps in naive format

The reason I ask is I was wondering whether the fix should be a backend rather than frontend fix, where the backend returns a non-ambiguous timestamp.

[villebro]

@villebro could you expand on what you mean by,

... backend returning timestamps in naive format

The reason I ask is I was wondering whether the fix should be a backend rather than frontend fix, where the backend returns a non-ambiguous timestamp.

@john-bodley yes, I think we should do that in the long run. However, at this point I felt it an unnecessarily risky change, as it might have far reaching implications for users that are relying on the current formatting behavior. Also, the fact that this functionality was broken in multiple ways on the frontend, including having either erroneous or missing tests (hence the regression), I felt it prudent to first get this area improved some more before proceeding to fixing the backend, which IMO has an even larger blast radius.