epoch_s columns not converted to timestamps correctly in 3.0.0rc3

[zhaorui2022]

We have datasets where we use unix timestamps (bigint) for time columns. Since upgraded to 3.0.0 (we noticed the issue after upgraded to 3.0.0rc3), those columns aren't converted to timestamps properly.

In 2.0.0, the temporal columns are converted with date_trunc('week', CAST(from_unixtime("col") AS TIMESTAMP)) AS "__timestamp", but in 3.0.0rc3, it is date_trunc('week', CAST("col" AS TIMESTAMP)) AS "col". For details, please see the recordings.

How to reproduce the bug

1. Create a dataset where it contains a column using various unix timestamps, and another column with random values. I use ts for the timestamp column and cnt for the other one. And also make sure the dataset has ts marked as temporal column and uses epoch_s. I have attached a screenshot of the sample dataset I used to reproduce the issue.
2. Create an area chart using the sample dataset
3. Choose ts column as the one for x-axis, and any aggregation for the other column
4. See error

Expected results

Expecting the temporal column being converted correctly, like in previous versions

Actual results

temporal column not being converted correctly

Screenshots

Here is the dataset temporal column config

Here is what's in 3.0.0rc3

3.0.0rc3.mp4

Here is what's in 2.0.0

2.0.0.mp4

Environment

(please complete the following information):

• browser type and version: Chrome, latest version
• superset version: superset version 3.0.0rc3
• python version: python --version 3.9
• node.js version: node -v N/A
• any feature flags active: I don't find any feature flag related with this issue

Checklist

Make sure to follow these steps before submitting your issue - thank you!

• I have checked the superset logs for python stacktraces and included it here as text if there are any.
• I have reproduced the issue with at least the latest released version of superset.
• I have checked the issue tracker for the same issue and I haven't found one similar.

Additional context

Add any other context about the problem here.

[john-bodley]

The underlying issue seems to be with the GENERIC_CHART_AXES feature, i.e., if you disable said feature the columns encoded as epoch or epoch_ms are handled correctly.