Shulou(Shulou.com)06/01 Report--

In this article, the editor introduces in detail "how to solve the time zone problem in django". The content is detailed, the steps are clear, and the details are handled properly. I hope this article "how to solve the time zone problem in django" can help you solve your doubts.

Preface

We all know the time zone, the standard time zone is UTC time zone, and django uses UTC time zone by default, so the time we store in the database is UTC time, but when our website is only for domestic users, or only provides internal platform for use, we want the time stored in the database to be local time (East eighth Zone time), then django can also accomplish this requirement.

Await time and navie time

What are await time and navie time? It is the two types of time in our python.

Navie: I don't know which time zone my time represents.

Await: know which time zone your time represents

Django sets East eighth District time

We want to change the time zone in django to the time of East eighth Zone. It's very simple.

USE_TZ = FalseTIME_ZONE = 'Asia/Shanghai'

Set USE_TZ to False and TIME_ZONE to Shanghai in the settings.py file, and then when we create the time field in the model, the time in the database is stored in the East eighth District, and the type of time will make the navie type, so we can no longer convert the time of navie type to the type of other time zone, so we generally do not recommend this.

Django sets the UTC time zone

UTC time zone is set by default in django, so the storage time in our database is the time of UTC time zone, that is, 0 time zone, which is 8 hours less than what we normally see, but its time is of await type and can be converted to any time zone.

The two-time method is provided in django

Django.utils.timezone.now: gets the current time based on whether USE_TZ=True is set in the settings.py file. If it is Ture, then get a UTC time of type aware, if it is False, then get a time of type navie

Django.utils.timezone.localtime: converts a time of type aware to the time of the TIME_ZONE specified time zone based on the TIME_ZONE in setting.py

The following is a list of several common time zone problems, and provide relevant reasons, if there is anything wrong, welcome to point out.

Question 1: the difference between datetime.datetime.now (), datetime.datetime.utcnow () and django.util.timezone.now () in three times

Datetime.datetime.now (): the output is always local time (naive time) regardless of configuration. Datetime.datetime.utcnow (): if USE_TZ=True is configured in setting, the output is UTC time (naive time), and if USE_TZ=False is configured in setting, the output time is exactly the same as datetime.datetime.now (). Django.util.timezone.now (): if USE_TZ=True is configured in setting, the output is UTC time (active time), and if USE_TZ=False is configured, it is exactly the same as datetime.datetime.now ().

Question 2: does the django store in the database 8 hours less than the local time?

First of all, to be clear, before the Django1.4 version, there was no concept of the time zone, and there was no processing for the access and display of time. The local time is usually stored in the database, of course, it is all naive time.

Django stores after version 1.4 if USE_TZ=True is set, the time stored in the database is always UTC time. At this point, if USE_TZ=True and TIME_ZONE are set in settings, the time obtained by UTC', with datetime.datetime.now () will be stored in the database as UTC time. If you modify the time obtained by USE_TZ=True and TIME_ZONE = 'Asia/Shanghai', with datetime.datetime.now () because there is no time zone, django will regard this time as Asia/Shanghai time, that is, East eighth Zone time, and then django will transfer this time to UTC time with time zone and store it in the database, and read it directly according to UTC time when reading. This is why many people online encounter that the time stored in the database is 8 hours less than the local time.

Question 3: DateTimeField role_cost_history.cost_time received a naive datetime (2015-05-12 19 5915 01.259517) while time zone support is active

This problem is because if you set USE_TZ=True and model thinks that DateTimeField uses UTC time (time with time zone), the time obtained with datetime.datetime.now () will report this problem.

Question 4: the output time of django.util.timezone.now () is 8 hours less than the local time.

As long as USE_TZ=True,django.util.timezone.now () is set, the output will always be UTC time, no matter what TIME_ZONE you set. If USE_TZ=False, the django.util.timezone.now () output is the same as datetime.datetime.now (), regardless of what TIME_ZONE is set to.

Question 5: template display time

After setting USE_TZ=True, if TIME_ZONE = 'Asia/Shanghai', is set, although the UTC time is stored in the database, when the template is displayed, it will be changed to the local time shown by TIME_ZONE.

Suggestion: in order to unify time, try to use UTC time when developing django, that is, set USE_TZ=True,TIME_ZONE = 'Asia/Shanghai', and use django.util.timezone.now () when getting time. Because the UTC time can be satisfied when the background program uses the time, and it can also ensure the correct display of the certificate template time.

After reading this, the article "how to solve the time zone problem with django" has been introduced. If you want to master the knowledge of this article, you still need to practice and use it. If you want to know more about the article, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.