aminghadersohi commented on code in PR #44805: URL: https://github.com/apache/superset/pull/44805#discussion_r4158844839
########## UPDATING.md: ########## @@ -24,6 +24,17 @@ assists people when migrating to a new version. ## Next +### SQLite time filters on `DATE` columns + +On SQLite, Shillelagh and the Superset meta database, a time filter on a `DATE` +column writes its bounds as a date, such as `'2026-09-20'`, and no longer uses +the column's **Datetime format** (`python_date_format`) or the database's +`python_date_format_by_column_name`. This fixes ranges that started and ended +one day late on `DATE` columns holding `YYYY-MM-DD` text. A `DATE` column that +holds values in another format, such as `20260920`, `09/20/2026` or epoch +seconds, is no longer filtered correctly. Columns declared as `INTEGER` are not +affected. Review Comment: Measured on SQLite: with Datetime format `%Y%m%d`, `%m/%d/%Y` or `epoch_s`, a two-day range on a `DATE` column returns 2 rows on master and 0 here, which is what an operator can spot. The Shillelagh cut of non-midnight bounds isn't noted either. ```suggestion one day late on `DATE` columns holding `YYYY-MM-DD` text. A `DATE` column that holds values in another format, such as `20260920`, `09/20/2026` or epoch seconds, now matches no rows, even with a Datetime format set. Columns declared as `INTEGER` are not affected. On Shillelagh and the meta database, a bound with a time of day is cut to its date. ``` -- 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]
