mysql backend creates queries using CONVERT_TZ even when this is not supported

[Klaas van Schelven]

To test whether a mysql server has the zoneinfo database loaded (feature name: has_zoneinfo_database), the ​following code is run:

CONVERT_TZ('2001-01-01 01:00:00', 'UTC', 'UTC') IS NOT NULL

However, this test is not actually used (i.e. there is no condition on the feature being True) when ​generating sql, despite the fact that the generated sql contains something that we know will evaluate to NULL, namely, the very same CONVERT_TZ mentioned in the above.

This shows up when filtering like so:

Foo.objects(some_datetimefield__date="2023-06-16")

which evaluates to the empty queryset, despite there being such objects. On a mysql database without the zoneinfo database loaded, and with USE_TZ = True, obviously

[Mariusz Felisiak]

Duplicate of e.g. #33075.

When USE_TZ is True, fields are converted to the current time zone before filtering (see ​__date docs). This requires ​time zone definitions in the database as documented (in both places).

[Klaas van Schelven]

"silently behaving incorrectly rather than failing explicitly, but documented" is an unsatisfactory answer to me, but I do admit that the point may be broader than the single weird behavior that I ran into. Couldn't we turn this into a django system check or similar?