You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The default value of USE_TZ will change from False to True in Django 5.0.
Set USE_TZ to False in your project settings if you want to keep the current default behavior.
USE_TZ = False
Investigate if we need to set USE_TZ to True.
It is interesting to notice that Django/Python and mySQL perform DST and standard time conversion when converting the timestamp (seconds_since_epoch) to date/time string.
Here are the timestamps taken from the following proc-cleanup-async-queues log entry:
log entry was created: on 11/08 at 09:42:00 PST,
the timestamp range for the select query is between t1=1730482920 and t2=1731087720
t2 is current timestamp, t1 = t2 - 606024*7 (a week in seconds)
this maps to date/time range: date1=2024-11-01 10:42:00 and date2=2024-11-08 09:42:00
note: date1 is PST while date2 is PDT
The date/time strings can be generated by using select from_unixtime(1730482920), from_unixtime(1731087720) and the datetime.fromtimestamp(seconds_since_epoch) function.
The text was updated successfully, but these errors were encountered:
A note from Django:
The default value of USE_TZ will change from False to True in Django 5.0.
Set USE_TZ to False in your project settings if you want to keep the current default behavior.
USE_TZ = False
Investigate if we need to set USE_TZ to True.
It is interesting to notice that Django/Python and mySQL perform DST and standard time conversion when converting the timestamp (seconds_since_epoch) to date/time string.
Here are the timestamps taken from the following
proc-cleanup-async-queues
log entry:The date/time strings can be generated by using
select from_unixtime(1730482920), from_unixtime(1731087720)
and thedatetime.fromtimestamp(seconds_since_epoch)
function.The text was updated successfully, but these errors were encountered: