Allow bigint to be used as time column in Presto

[betodealmeida]

SUMMARY

We have a table in Presto where the temporal column is a BIGINT, representing a unix timestamp. This allows us to use it as a temporal column in the explore view.

TEST PLAN

Previous query:

SELECT COUNT(*) AS "count"
FROM "superset"."logs"
WHERE "dttm" >= '2019-03-27 00:00:00'
  AND "dttm" <= '2019-04-03 00:00:00'
ORDER BY "count" DESC
LIMIT 10000;

Now:

SELECT COUNT(*) AS "count"
FROM "superset"."logs"
WHERE "dttm" >= to_unixtime(from_iso8601_timestamp('2019-03-27T00:00:00'))
  AND "dttm" <= to_unixtime(from_iso8601_timestamp('2019-04-03T00:00:00'))
ORDER BY "count" DESC
LIMIT 10000;

ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Changes UI
[ ] Requires DB Migration. Confirm DB Migration upgrade and downgrade tested.
[x] Introduces new feature or API
[ ] Removes existing feature or API
[ ] Fixes bug
[ ] Refactors code
[ ] Adds test(s)

REVIEWERS

@xtinec @DiggidyDave @datability-io @khtruong

[codecov-io]

Codecov Report

Merging #7218 into lyftga will decrease coverage by <.01%.
The diff coverage is 0%.

@@            Coverage Diff            @@
##           lyftga   #7218      +/-   ##
=========================================
- Coverage    64.5%   64.5%   -0.01%     
=========================================
  Files         424     424              
  Lines       20667   20669       +2     
  Branches     2268    2268              
=========================================
  Hits        13332   13332              
- Misses       7212    7214       +2     
  Partials      123     123

Impacted Files	Coverage Δ
superset/db_engine_specs.py	57.23% <0%> (-0.15%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 200efac...46285bf. Read the comment docs.

[xtinec]

LGTM

[john-bodley]

@betodealmeida I don't think this change is valid as a BIGINT could represent an epoch timestamp in either seconds or milliseconds. Due to this ambiguity one would need to specify either epoch or epoch_ms for the python_date_format field.

Note as part of SIP-15 I plan to add date-time inferencing for non-temporal fields, i.e., string like and numeric which both support multiple date-time encodings.

[mistercrunch]

Maybe on fetch_metadata we could try and do smart auto-detection based on a sample of the data

[john-bodley]

@mistercrunch please see #7653 which proposes a solution to this.