I am at a loss. What I'm doing is very simple and works in dev but not prod.
I have a model, EmailLog, which contains a DateTimeField with a default of timezone.now. Model is created in database with the correct timestamp.
I would like to display any models that were created today.
Model Snippet
class EmailLog(models.Model):
created_on = models.DateTimeField(default=timezone.now)
...
Model shows in database as 2023-05-10 16:31:34.381 for created_on and a raw print(log.created_on) shows 2023-05-10 16:31:34.381741+00:00
I'm attempting to pull logs for today like so
logs = list(EmailLog.objects.filter(created_on__day=10, created_on__month=5))
This works perfectly fine in dev, in production I'm given no results but also no errors.
I've tried created_on__date=timezone.now().date(), created_on__gte=timezone.now().date(), also tried various forms of the date in string ISO format 2023-05-10, I've tried created_on__range=(start_date,end_date) where start_date is 2023-05-10 00:00:00 and end_date is 2023-05-10 23:59:59 and I get nothing.
Both dev and prod database are MySQL, but quite possibly different versions as the production app is in Azure using an Azure MySQL. That is the only difference I can see between app deployments, both are using a virtual env, both configured with some packages, all managed with poetry and identical.
I'm at a loss, please point out the bonehead mistake I'm making.
As explained in this article, MySQL uses (well what would it use otherwise) a table to store the timezones and how these are converted.
For some reason, this table might be truncated, and thus the conversion to a different timezone fails. It is a bit sad that the database then returns NULL, and does not raise some error.
Anyway, a system usually has some tools to list the timezones. In Unix/Linux systems for example, that data is contained in the tz-info package of most package managers. Files are then stored in the /usr/share/zoneinfo directory to specify how these timezones are defined.
Azure MySQL databases have a stored procedure that can inspect the timezones on the system, and then fill the corresponding tables with information regarding these timezones. You can do this in a MySQL session with:
mysql> CALL mysql.az_load_timezone();
You might even want to run this command every now and then, to let the timezones keep in sync. Every now and then the specifics of some timezones change (slightly). MySQL will not look for the conversion to the data stored in the system, but in its tables.