English is the default language of the project. When I switch language, values of all date fields are disrepair. When I try to fill up the form and send it, appear this error: RuntimeWarning: DateTimeField received a naive datetime (2022-11-27 12:00:00.045143) while time zone support is active.
I think the problem with time zone. if make this USE_TZ = False the translation is not working at all...
Related
I have deleted all timezone-naive entries out of my Sqlite-DB. So now they remaining entries have a datefield like this:
2016-09-04 13:28:16+00
When I now run my query like this:
result = Feedentry.objects.filter(date_published__gt=timezone('Europe/Berlin').localize(datetime(2016, 8, 31, 17)))
First I receive no error, but as soon as I want to access the result (or len(result)) I receive the following error:
raise ValueError('Not naive datetime (tzinfo is already set)')
Any ideas how to solve it or what I did wrong?
Django always stores datetimes in UTC. And in SQLite it doesn't store any timezone information at all:
[Databases other than PostgreSQL] store datetimes without time zone information. If you switch from USE_TZ = False to USE_TZ = True, you must convert your data from local time to UTC – which isn’t deterministic if your local time has DST.
So first you need to go through your database and convert all the values to UTC; otherwise, Django will not interpret the values correctly.
As for your comparison, it is correct if you're using pytz.timezone and a naive datetime. But the error message implies that whatever datetime you're passing to localize() is already timezone-aware. To convert a timezone-aware datetime you need to use datetime.astimezone(), as noted in the pytz documentation.
I'm using ReportLab in Django. I have a model with the following field:
time_stamp = models.DateTimeField(auto_now_add=True)
And my TIME_ZONE variable in settings.py is set to:
Africa/Johannesburg
I use a formset to populate this model. The time_stamp field saves correctly with the correct time zone, but when I place the time_stamp in my ReportLab pdf, the time zone is set to UTC.
For example:
time_stamp in the saved model (as str(time_stamp)[:19] is:
2015-03-04 07:57:28
But time_stamp in pdf document (as str(time_stamp)[:19] is:
2015-03-04 05:57:28
Exactly 2 hours earlier (Africa/Johannesburg is UTC + 2hours).
How can I set the time zone for ReportLab? Should it be specified in settings.py or in views.py while generating the pdf? If there is no solution, how do I add 2 hours to the time_stamp?
Some answers suggested changing auto_now_add=True with default=datetime.datetime.now(), but this creates a warning while migrating the database (Naive expression used).
I'm not a user of Reportlab but in general I don't think setting USE_TZ=False is the right approach to solve your problem. Set it back to True and instead of truncating your time stamp yourself like:
str(time_stamp)[:19]
You should try applying Django's date template filter in your template, e.g.:
{{ time_stamp|date:"SHORT_DATETIME_FORMAT" }}
It can be confusing how Django is handling timezones. But it's best practice to save timestamps in your database in UTC. You may want to refer to Django's timezone FAQ:
https://docs.djangoproject.com/en/dev/topics/i18n/timezones/#time-zones-faq
I have :
TIME_ZONE = 'Europe/Paris'
USE_L10N = True
USE_TZ = True
in my settings.py file. I am living in Istanbul/Turkey and there is one hour difference between Paris and Istanbul.
In the admin side when selecting a date, django correctly shows 1 hour difference. And using template tag i am getting the datetime i have set in the admin.
But when i pass the datetime via python using beginning_date.strftime("%H:%M") python substracts 1 hour from the value that was set via admin which is not true.
How can i solve this?
Use the Django template defaultfilters to format your dates in Python code.
from django.template.defaultfilters import date as _date
_date(datetime_object, "%H:%M")
And, maybe related: Django cannot reliably use alternate time zones in a Windows. See documentation.
I don't think Turkey has anything to do with it.
My guess is that the one-hour difference you're seeing is between the Paris timezone—which is being used, by default, to interpret and display dates—and UTC—which is being used to store the datetime, and which is the timezone of the datetime returned from the database.
If that's correct, then you can just use django.utils.timezone.localtime to convert the datetime to the current time zone (which by default will be TIME_ZONE):
localtime(beginning_date).strftime("%H:%M")
How does Django internally store a datetime field? Does it translate local time to UTC before storing? I am giving it a naive datetime generated from stdlib.
a = Message( fromm = fromm, to = to,
sent_time = datetime.datetime.now(), content = content)
Django ORM stores date time in your SQL database's corresponding field. The underlying SQL column is determined by the used database. E.g. for MySQL, the mappings are defined here:
https://github.com/django/django/blob/master/django/db/backends/mysql/creation.py#L16
Conversion from Django to SQL:
https://github.com/django/django/blob/master/django/db/backends/mysql/base.py#L272
Conversion from SQL to Django:
https://github.com/django/django/blob/master/django/db/models/fields/init.py#L1186
Python datetime.datetime.now() is so-called timezone-naive datetime and doesn't have any timezone information. Thus, you may lose information when storing times with it and it's usage is discouraged. It returns the local time. It seems that that if timezone information is omitted, the Django USE_TZ setting determines if the default timezone information is retrofitted internally.
Instead, you should use django.utils.timezone.now() (local time with timezone) or django.utils.timezone.utcnow() (time with UTC timezone).
More info
https://docs.djangoproject.com/en/dev/topics/i18n/timezones/#naive-and-aware-datetime-objects
using django 1.4 I have a model with a datetimefield. I imported django.utils.timezone to use as the default value.
from django.utils import timezone
date = models.DateTimeField(default=timezone.now)
however I still receive the warning about DateTimeField received naive date.
i have set USE_TZ to true so it should be returning aware datetimes
djangos putting in a default date value that isn't tz aware because the field isnt nullable by default. setting null to true means it will just set the date to to NULL instead so the warning isnt raised:
date = models.DateTimeField(default=timezone.now, null=True)
In my case, I kept receiving the issue when I ran tests. This is because of a past migration that incorrectly used datetime instead of timezone. I reverted back to the migration before the one causing the warning, deleted it, ran makemigrations again. This solved the issue for me.
now()
Returns an aware or naive datetime that represents the current
point in time when USE_TZ is True or False respectively.
https://docs.djangoproject.com/en/dev/ref/utils/#django.utils.timezone.now
I know this is side-stepping the issue but have you tried auto_now_add=True on your field instead? No need to use default for what you want.
On the other hand your version should work as well if you have indeed USE_TZ=True.
I'd say it does work, and you get the RunTimeWarning from somewhere where you set the date field directly instead and not from the default. Try to narrow down when is the warning triggered more exactly.