Django 2.1 - Time zones

समय क्षेत्र




django

समय क्षेत्र

अवलोकन

जब समय क्षेत्र के लिए समर्थन सक्षम किया जाता है, तो Django डेटाबेस में UTC में डेटाटाइम जानकारी संग्रहीत करता है, आंतरिक रूप से समय-क्षेत्र-जागरूक डेटाटाइम ऑब्जेक्ट का उपयोग करता है, और उन्हें अंत उपयोगकर्ता के समय क्षेत्र में टेम्पलेट और रूपों में अनुवाद करता है।

यह आसान है यदि आपके उपयोगकर्ता एक से अधिक समय क्षेत्र में रहते हैं और आप प्रत्येक उपयोगकर्ता की दीवार घड़ी के अनुसार डेटाटाइम जानकारी प्रदर्शित करना चाहते हैं।

भले ही आपकी वेबसाइट केवल एक समय क्षेत्र में उपलब्ध है, फिर भी आपके डेटाबेस में डेटा को UTC में संग्रहीत करना अच्छा है। इसका मुख्य कारण डेलाइट सेविंग टाइम (DST) है। कई देशों में डीएसटी की एक प्रणाली है, जहां घड़ियों को वसंत में आगे और शरद ऋतु में पीछे की ओर ले जाया जाता है। यदि आप स्थानीय समय में काम कर रहे हैं, तो आप वर्ष में दो बार त्रुटियों का सामना कर सकते हैं, जब संक्रमण होता है। ( pytz प्रलेखन इन मुद्दों पर अधिक विस्तार से चर्चा करता है।) यह संभवतः आपके ब्लॉग के लिए मायने नहीं रखता है, लेकिन यह समस्या है कि यदि आप अपने ग्राहकों को हर साल एक घंटे, दो बार एक से अधिक बिल या अंडर-बिल देते हैं। इस समस्या का समाधान कोड में यूटीसी का उपयोग करना है और स्थानीय समय का उपयोग केवल अंत उपयोगकर्ताओं के साथ बातचीत करते समय करना है।

समय क्षेत्र समर्थन डिफ़ॉल्ट रूप से अक्षम है। इसे सक्षम करने के लिए, अपनी सेटिंग फ़ाइल में USE_TZ = True सेट करें। समय क्षेत्र समर्थन pytz का उपयोग करता है, जो कि जब आप Django स्थापित करते हैं तो स्थापित होता है।

ध्यान दें

django-admin startproject द्वारा बनाई गई डिफ़ॉल्ट django-admin startproject फ़ाइल में सुविधा के लिए USE_TZ = True शामिल है।

ध्यान दें

एक स्वतंत्र लेकिन संबंधित USE_L10N सेटिंग भी है जो नियंत्रित करती है कि क्या Django को प्रारूप स्थानीयकरण को सक्रिय करना चाहिए। अधिक विवरण के लिए प्रारूप स्थानीयकरण देखें।

यदि आप एक विशेष समस्या के साथ कुश्ती कर रहे हैं, तो समय क्षेत्र FAQ से शुरू करें।

अवधारणाओं

Naive और जागरूक डेटाटाइम ऑब्जेक्ट्स

पायथन के datetime.datetime वस्तुओं में एक tzinfo विशेषता है जो टाइम ज़ोन सूचना को संग्रहीत करने के लिए उपयोग किया जा सकता है, जिसे datetime.tzinfo उपवर्ग के एक उदाहरण के रूप में दर्शाया गया है। जब यह विशेषता सेट होती है और ऑफ़सेट का वर्णन करती है, तो एक डेटाटाइम ऑब्जेक्ट ज्ञात होता है । नहीं तो भोली है

आप यह निर्धारित करने के लिए is_aware() और is_naive() का उपयोग कर सकते हैं कि क्या datetimes जागरूक हैं या अनुभवहीन हैं।

जब समय क्षेत्र समर्थन अक्षम हो जाता है, तो Django स्थानीय समय में भोली डेटाइम वस्तुओं का उपयोग करता है। यह कई उपयोग मामलों के लिए सरल और पर्याप्त है। इस मोड में, वर्तमान समय प्राप्त करने के लिए, आप लिखेंगे:

import datetime

now = datetime.datetime.now()

जब समय क्षेत्र समर्थन सक्षम होता है ( USE_TZ=True ), तो Django समय-क्षेत्र-जागरूक डेटाटाइम ऑब्जेक्ट का उपयोग करता है। यदि आपका कोड डेटाटाइम ऑब्जेक्ट बनाता है, तो उन्हें भी जागरूक होना चाहिए। इस मोड में, ऊपर दिया गया उदाहरण बनता है:

from django.utils import timezone

now = timezone.now()

चेतावनी

जागरूक डेटाटाइम ऑब्जेक्ट के साथ व्यवहार करना हमेशा सहज नहीं होता है। उदाहरण के लिए, मानक tzinfo का tzinfo तर्क DST के साथ समय क्षेत्र के लिए मज़बूती से काम नहीं करता है। यूटीसी का उपयोग करना आम तौर पर सुरक्षित है; यदि आप अन्य समय क्षेत्रों का उपयोग कर रहे हैं, तो आपको pytz प्रलेखन की सावधानीपूर्वक समीक्षा करनी चाहिए।

ध्यान दें

पायथन के tzinfo ऑब्जेक्ट में एक tzinfo विशेषता भी tzinfo है, और PostgreSQL में time with time zone प्रकार के time with time zone मेल खाता है। हालाँकि, जैसा कि PostgreSQL के डॉक्स ने रखा, यह प्रकार "गुण प्रदर्शित करता है जो संदिग्ध उपयोगिता की ओर ले जाता है"।

Django केवल भोले समय की वस्तुओं का समर्थन करता है और एक अपवाद को बढ़ाएगा यदि आप किसी जागरूक समय ऑब्जेक्ट को बचाने का प्रयास करते हैं, क्योंकि समय के साथ कोई संबंधित तारीख के साथ समय का कोई मतलब नहीं है।

भोली-भाली वस्तुओं की व्याख्या

जब USE_TZ True , तो Django अभी भी भोली- USE_TZ वस्तुओं को स्वीकार करता है, ताकि पश्च-संगतता को संरक्षित किया जा सके। जब डेटाबेस लेयर एक प्राप्त करता है, तो वह इसे डिफ़ॉल्ट समय क्षेत्र में व्याख्या करके जागरूक करने का प्रयास करता है और चेतावनी देता है।

दुर्भाग्य से, डीएसटी संक्रमण के दौरान, कुछ डेटासेट मौजूद नहीं हैं या अस्पष्ट हैं। ऐसी स्थितियों में, pytz एक अपवाद उठाता है। इसीलिए समय क्षेत्र का समर्थन सक्षम होने पर आपको हमेशा जागरूक डेटाटाइम ऑब्जेक्ट बनाना चाहिए।

व्यवहार में, यह शायद ही कभी एक मुद्दा है। Django आपको मॉडल और रूपों में जागरूक डेटाइम ऑब्जेक्ट्स देता है, और सबसे अधिक बार, नए डेटाटाइम ऑब्जेक्ट्स को timedelta अंकगणित के माध्यम से मौजूदा लोगों से बनाया जाता है। अनुप्रयोग कोड में अक्सर बनाया जाने वाला एकमात्र डेटाटाइम वर्तमान समय है, और timezone.now() स्वचालित रूप से सही काम करता है।

डिफ़ॉल्ट समय क्षेत्र और वर्तमान समय क्षेत्र

डिफ़ॉल्ट समय क्षेत्र TIME_ZONE सेटिंग द्वारा परिभाषित समय क्षेत्र है।

वर्तमान समय क्षेत्र वह समय क्षेत्र है जिसका उपयोग प्रतिपादन के लिए किया जाता है।

आपको उपयोगकर्ता के वास्तविक समय क्षेत्र को activate() साथ वर्तमान समय क्षेत्र सेट करना चाहिए। अन्यथा, डिफ़ॉल्ट समय क्षेत्र का उपयोग किया जाता है।

ध्यान दें

जैसा कि TIME_ZONE के प्रलेखन में समझाया गया है, Django पर्यावरण चर निर्धारित करता है ताकि इसकी प्रक्रिया डिफ़ॉल्ट समय क्षेत्र में चले। यह USE_TZ के मान और वर्तमान समय क्षेत्र की परवाह किए बिना होता है।

जब USE_TZ True , तो यह उन अनुप्रयोगों के साथ पश्चगामी-संगतता बनाए रखने के लिए उपयोगी है जो अभी भी स्थानीय समय पर निर्भर हैं। हालाँकि, जैसा कि ऊपर बताया गया है , यह पूरी तरह से विश्वसनीय नहीं है, और आपको हमेशा अपने कोड में UTC में जागरूक डेटासेट के साथ काम करना चाहिए। उदाहरण के लिए, fromtimestamp() उपयोग करें और utc पैरामीटर को utc सेट करें।

वर्तमान समय क्षेत्र का चयन करना

वर्तमान समय क्षेत्र अनुवादों के लिए वर्तमान locale के बराबर है। हालाँकि, Accept-Language HTTP हेडर के बराबर नहीं है जो Django उपयोगकर्ता के समय क्षेत्र को स्वचालित रूप से निर्धारित करने के लिए उपयोग कर सकता है। इसके बजाय, Django समय क्षेत्र चयन कार्य प्रदान करता है । समय क्षेत्र चयन तर्क बनाने के लिए उनका उपयोग करें जो आपके लिए समझ में आता है।

टाइम ज़ोन की देखभाल करने वाली अधिकांश वेबसाइटें उपयोगकर्ताओं से पूछती हैं कि वे किस समय क्षेत्र में रहते हैं और उपयोगकर्ता की प्रोफ़ाइल में इस जानकारी को संग्रहीत करते हैं। अनाम उपयोगकर्ताओं के लिए, वे अपने प्राथमिक दर्शकों या यूटीसी के समय क्षेत्र का उपयोग करते हैं। pytz देश के प्रति समय क्षेत्र की सूची की तरह pytz प्रदान करता है, जिसका उपयोग आप सबसे अधिक संभावित विकल्पों का चयन करने के लिए कर सकते हैं।

यहां एक उदाहरण दिया गया है जो सत्र में वर्तमान समय क्षेत्र को संग्रहीत करता है। (यह पूरी तरह से सरलता के लिए त्रुटि से निपटने में सहायता करता है।)

MIDDLEWARE में निम्न मिडिलवेयर जोड़ें:

import pytz

from django.utils import timezone
from django.utils.deprecation import MiddlewareMixin

class TimezoneMiddleware(MiddlewareMixin):
    def process_request(self, request):
        tzname = request.session.get('django_timezone')
        if tzname:
            timezone.activate(pytz.timezone(tzname))
        else:
            timezone.deactivate()

एक दृश्य बनाएं जो वर्तमान समय क्षेत्र सेट कर सकता है:

from django.shortcuts import redirect, render

def set_timezone(request):
    if request.method == 'POST':
        request.session['django_timezone'] = request.POST['timezone']
        return redirect('/')
    else:
        return render(request, 'template.html', {'timezones': pytz.common_timezones})

template.html में एक फ़ॉर्म शामिल करें। POST जो इस दृश्य को POST करेगा:

{% load tz %}
{% get_current_timezone as TIME_ZONE %}
<form action="{% url 'set_timezone' %}" method="POST">
    {% csrf_token %}
    <label for="timezone">Time zone:</label>
    <select name="timezone">
        {% for tz in timezones %}
        <option value="{{ tz }}"{% if tz == TIME_ZONE %} selected{% endif %}>{{ tz }}</option>
        {% endfor %}
    </select>
    <input type="submit" value="Set">
</form>

रूपों में समय क्षेत्र जागरूक इनपुट

जब आप समय क्षेत्र समर्थन को सक्षम करते हैं, तो Django वर्तमान समय क्षेत्र में फ़ॉर्म में दर्ज किए गए cleaned_data व्याख्या करता है और cleaned_data में जागरूक cleaned_data ऑब्जेक्ट cleaned_data

यदि वर्तमान समय क्षेत्र pytz अपवाद को उठाता है जो अस्तित्व में नहीं है या अस्पष्ट हैं क्योंकि वे एक डीएसटी संक्रमण ( pytz द्वारा प्रदान किए गए pytz ) में आते हैं, तो ऐसे pytz को अमान्य मान के रूप में रिपोर्ट किया जाएगा।

टेम्प्लेट में समय क्षेत्र जागरूक आउटपुट

जब आप समय क्षेत्र समर्थन सक्षम करते हैं, तो Django वर्तमान समय क्षेत्र में जागरूक डेटाटाइम ऑब्जेक्ट्स को तब परिवर्तित करता है जब वे टेम्प्लेट में प्रस्तुत किए जाते हैं। यह प्रारूपण स्थानीयकरण की तरह बहुत व्यवहार करता है।

चेतावनी

Django भोली डेटाइम वस्तुओं को परिवर्तित नहीं करता है, क्योंकि वे अस्पष्ट हो सकते हैं, और क्योंकि आपके कोड को कभी भी भोले डेटासेट का उत्पादन नहीं करना चाहिए जब समय क्षेत्र समर्थन सक्षम होता है। हालाँकि, आप नीचे वर्णित टेम्पलेट फ़िल्टर के साथ रूपांतरण को बाध्य कर सकते हैं।

स्थानीय समय में रूपांतरण हमेशा उचित नहीं होता है - आप इंसानों के बजाय कंप्यूटर के लिए आउटपुट उत्पन्न कर सकते हैं। निम्नलिखित फ़िल्टर और टैग, tz टेम्पलेट टैग लाइब्रेरी द्वारा प्रदान किए गए हैं, जिससे आप समय क्षेत्र रूपांतरणों को नियंत्रित कर सकते हैं।

टेम्प्लेट टैग

localtime

निहित ब्लॉक में वर्तमान समय क्षेत्र के लिए जागरूक डेटाटाइम ऑब्जेक्ट के रूपांतरण को सक्षम या अक्षम करता है।

यह टैग बिल्कुल उसी तरह का प्रभाव है जैसा कि USE_TZ सेटिंग जहां तक ​​टेम्पलेट इंजन का संबंध है। यह रूपांतरण का अधिक महीन दानेदार नियंत्रण की अनुमति देता है।

टेम्पलेट ब्लॉक के लिए रूपांतरण सक्रिय या निष्क्रिय करने के लिए, उपयोग करें:

{% load tz %}

{% localtime on %}
    {{ value }}
{% endlocaltime %}

{% localtime off %}
    {{ value }}
{% endlocaltime %}

ध्यान दें

USE_TZ का मान {% localtime %} ब्लॉक के अंदर नहीं है।

timezone

सम्‍मिलित ब्‍लॉक में वर्तमान समय क्षेत्र सेट या अनसेट करता है। जब वर्तमान समय क्षेत्र अप्रभावित होता है, तो डिफ़ॉल्ट समय क्षेत्र लागू होता है।

{% load tz %}

{% timezone "Europe/Paris" %}
    Paris time: {{ value }}
{% endtimezone %}

{% timezone None %}
    Server time: {{ value }}
{% endtimezone %}

get_current_timezone

आप get_current_timezone टैग का उपयोग करके वर्तमान समय क्षेत्र का नाम प्राप्त कर सकते हैं:

{% get_current_timezone as TIME_ZONE %}

वैकल्पिक रूप से, आप tz() संदर्भ प्रोसेसर को सक्रिय कर सकते हैं और TIME_ZONE संदर्भ चर का उपयोग कर सकते हैं।

खाका फिल्टर

ये फ़िल्टर जागरूक और भोले दोनों प्रकार के डेटासेट को स्वीकार करते हैं। रूपांतरण उद्देश्यों के लिए, वे मानते हैं कि भोले डेटासेटाइम डिफ़ॉल्ट समय क्षेत्र में हैं। वे हमेशा जागरूक डेटाटाइम्स लौटाते हैं।

localtime

वर्तमान समय क्षेत्र के लिए एकल मान का रूपांतरण।

उदाहरण के लिए:

{% load tz %}

{{ value|localtime }}

utc

यूटीसी के लिए एक एकल मूल्य का रूपांतरण।

उदाहरण के लिए:

{% load tz %}

{{ value|utc }}

timezone

एक मनमाना समय क्षेत्र में एकल मूल्य के रूपांतरण को मजबूर करता है।

तर्क को एक datetime.tzinfo उपवर्ग या समय क्षेत्र नाम का उदाहरण होना चाहिए।

उदाहरण के लिए:

{% load tz %}

{{ value|timezone:"Europe/Paris" }}

माइग्रेशन गाइड

यहां बताया गया है कि कैसे एक परियोजना को स्थानांतरित करना शुरू किया गया था जो कि Django के समय क्षेत्र के लिए समर्थित था।

डेटाबेस

PostgreSQL

PostgreSQL बैकएंड timestamp with time zone रूप में timestamp with time zone स्टोर timestamp with time zone । व्यवहार में, इसका अर्थ है कि यह कनेक्शन के टाइम ज़ोन से UTC तक संग्रहण पर डेटाटाइम्स को परिवर्तित करता है, और UTC से कनेक्शन के टाइम ज़ोन को पुनः प्राप्ति पर।

परिणामस्वरूप, यदि आप PostgreSQL का उपयोग कर रहे हैं, तो आप USE_TZ = False और USE_TZ = True आज़ादी के बीच स्विच कर सकते हैं। डेटाबेस कनेक्शन का टाइम ज़ोन क्रमशः TIME_ZONE या UTC सेट किया जाएगा, ताकि Django सभी मामलों में सही डेटासेट प्राप्त करे। आपको कोई भी डेटा रूपांतरण करने की आवश्यकता नहीं है।

अन्य डेटाबेस

अन्य बैकएंड समय की जानकारी के बिना डेटासेट स्टोर करते हैं। यदि आप USE_TZ = False से USE_TZ = True स्विच करते हैं, तो आपको अपना डेटा स्थानीय समय से UTC में बदलना होगा - जो कि निर्धारित नहीं है यदि आपके स्थानीय समय में DST है।

कोड

पहला चरण अपनी सेटिंग फ़ाइल में USE_TZ = True जोड़ना है। इस बिंदु पर, चीजों को ज्यादातर काम करना चाहिए। यदि आप अपने कोड में भोली-भाली वस्तुओं का निर्माण करते हैं, तो Django उन्हें आवश्यक होने पर जागरूक करता है।

हालाँकि, ये रूपांतरण डीएसटी बदलावों के आसपास विफल हो सकते हैं, जिसका अर्थ है कि आपको अभी तक समय क्षेत्र समर्थन का पूरा लाभ नहीं मिल रहा है। साथ ही, आपको कुछ समस्याओं में भाग लेने की संभावना है, क्योंकि एक जागरूक डेटाइम के साथ एक भोली उम्र की तुलना करना असंभव है। चूँकि Django अब आपको जागरूक डेटासेट देता है, आप अपवादों को प्राप्त करेंगे, जहाँ आप एक मॉडल से आए हुए एक डेटाइम की तुलना करते हैं या एक भोले डेटाइम के साथ एक फॉर्म जिसे आपने अपने कोड में बनाया है।

तो दूसरा चरण यह है कि आप अपने कोड को फिर से रिफेंक्ट करें जहाँ भी आप उन्हें अवगत कराने के लिए डेटाटाइम ऑब्जेक्ट्स को इंस्टेंट करते हैं। यह वृद्धिशील रूप से किया जा सकता है। django.utils.timezone संगतता कोड के लिए कुछ उपयोगी सहायकों को परिभाषित करता है: timezone.now() , is_aware() , is_naive() , make_aware() , और make_naive()

अंत में, आपको उस कोड का पता लगाने में मदद करने के लिए, जिसे अपग्रेड करने की आवश्यकता है, Django एक चेतावनी उठाता है जब आप डेटाबेस के लिए एक भोले डेटाटाइम को बचाने का प्रयास करते हैं:

RuntimeWarning: DateTimeField ModelName.field_name received a naive
datetime (2012-01-01 00:00:00) while time zone support is active.

विकास के दौरान, आप ऐसी चेतावनियों को अपवाद में बदल सकते हैं और अपनी सेटिंग फ़ाइल में निम्न जोड़कर एक ट्रेसबैक प्राप्त कर सकते हैं:

import warnings
warnings.filterwarnings(
    'error', r"DateTimeField .* received a naive datetime",
    RuntimeWarning, r'django\.db\.models\.fields',
)

फिक्स्चर

एक जागरूक डेटाटाइम को क्रमबद्ध करते समय, UTC ऑफसेट को इस तरह शामिल किया जाता है:

"2011-09-01T13:20:30+03:00"

एक भोली उम्र के लिए, यह स्पष्ट रूप से नहीं है:

"2011-09-01T13:20:30"

DateTimeField s वाले मॉडल के लिए, यह अंतर उस स्थिरता को लिखना असंभव बनाता है जो समय क्षेत्र समर्थन के साथ और उसके बिना काम करता है।

USE_TZ = False , या Django 1.4 से पहले उत्पन्न जुड़नार, "भोले" प्रारूप का उपयोग करें। यदि आपकी परियोजना में ऐसे जुड़नार हैं, तो आप समय क्षेत्र समर्थन को सक्षम करने के बाद, जब आप उन्हें लोड करते हैं तो आप RuntimeWarning s देखेंगे। चेतावनी से छुटकारा पाने के लिए, आपको अपने जुड़नार को "जागरूक" प्रारूप में बदलना होगा।

आप loaddata साथ जुड़नार फिर loaddata कर सकते हैं। या, यदि वे पर्याप्त छोटे हैं, तो आप उन्हें यूटीसी ऑफसेट जोड़ने के लिए संपादित कर सकते हैं जो प्रत्येक धारावाहिक TIME_ZONE लिए आपके TIME_ZONE से मेल खाता है।

सामान्य प्रश्न

सेट अप

  1. मुझे कई समय क्षेत्रों की आवश्यकता नहीं है। क्या मुझे समय क्षेत्र का समर्थन सक्षम करना चाहिए?

    हाँ। जब समय क्षेत्र समर्थन सक्षम होता है, तो Django स्थानीय समय के अधिक सटीक मॉडल का उपयोग करता है। यह आपको डेलाइट सेविंग टाइम (डीएसटी) बदलावों के आसपास सूक्ष्म और अपरिवर्तनीय बग से बचाता है।

    जब आप समय क्षेत्र समर्थन को सक्षम करते हैं, तो आप कुछ त्रुटियों का सामना करेंगे क्योंकि आप भोले डेटासेट का उपयोग कर रहे हैं जहां Django जागरूक डेटासेट की अपेक्षा करता है। परीक्षण चलाते समय ऐसी त्रुटियां दिखाई देती हैं और उन्हें ठीक करना आसान होता है। आप जल्दी से सीखेंगे कि अमान्य कार्यों से कैसे बचें।

    दूसरी ओर, समय क्षेत्र समर्थन की कमी के कारण होने वाली बग को रोकने, निदान करने और ठीक करने के लिए बहुत कठिन हैं। कुछ भी जिसमें अनुसूचित कार्य या डेटाटाइम अंकगणित शामिल है, सूक्ष्म बग के लिए एक उम्मीदवार है जो आपको साल में केवल एक या दो बार काटेगा।

    इन कारणों से, नई परियोजनाओं में समय क्षेत्र का समर्थन डिफ़ॉल्ट रूप से सक्षम है, और आपको इसे तब तक रखना चाहिए जब तक आपके पास बहुत अच्छा कारण न हो।

  2. मैंने समय क्षेत्र समर्थन सक्षम किया है। क्या मैं सुरक्षित हूं?

    शायद। आप डीएसटी से संबंधित बगों से बेहतर तरीके से सुरक्षित हैं, लेकिन फिर भी आप अपने पैरों को लापरवाह तरीके से भोले-भाले लोगों को जागरूक डेटासेट में बदल सकते हैं, और इसके विपरीत।

    यदि आपका एप्लिकेशन अन्य सिस्टम से कनेक्ट होता है - उदाहरण के लिए, यदि यह वेब सेवा पर सवाल उठाता है - तो सुनिश्चित करें कि डेटासेट ठीक से निर्दिष्ट हैं। डेटाटाइम को सुरक्षित रूप से प्रसारित करने के लिए, उनके प्रतिनिधित्व में यूटीसी ऑफसेट शामिल होना चाहिए, या उनका मान यूटीसी (या दोनों) में होना चाहिए।

    अंत में, हमारे कैलेंडर सिस्टम में कंप्यूटर के लिए दिलचस्प जाल हैं:

    >>> import datetime
    >>> def one_year_before(value):       # DON'T DO THAT!
    ...     return value.replace(year=value.year - 1)
    >>> one_year_before(datetime.datetime(2012, 3, 1, 10, 0))
    datetime.datetime(2011, 3, 1, 10, 0)
    >>> one_year_before(datetime.datetime(2012, 2, 29, 10, 0))
    Traceback (most recent call last):
    ...
    ValueError: day is out of range for month
    

    (इस फ़ंक्शन को लागू करने के लिए, आपको यह तय करना होगा कि क्या 2012-02-29 माइनस एक वर्ष 2011-02-28 या 2011-03-01 है, जो आपकी व्यक्तिगत आवश्यकताओं पर निर्भर करता है।)

  3. मैं स्थानीय समय में डेटासेट स्टोर करने वाले डेटाबेस के साथ कैसे इंटरैक्ट करता हूं?

    DATABASES सेटिंग में इस डेटाबेस के लिए उचित समय क्षेत्र में TIME_ZONE विकल्प सेट करें।

    यह उस डेटाबेस से जुड़ने के लिए उपयोगी है जो समय क्षेत्र का समर्थन नहीं करता है और जब USE_TZ True है तो Django द्वारा प्रबंधित नहीं किया गया है।

समस्या निवारण

  1. TypeError: can't compare offset-naive साथ मेरा एप्लिकेशन क्रैश हो गया TypeError: can't compare offset-naive and offset-aware datetimes TypeError: can't compare offset-naive - क्या गलत है?

    आइए एक भोले और एक जागरूक डेटाइम की तुलना करके इस त्रुटि को पुन: उत्पन्न करें:

    >>> import datetime
    >>> from django.utils import timezone
    >>> naive = datetime.datetime.utcnow()
    >>> aware = timezone.now()
    >>> naive == aware
    Traceback (most recent call last):
    ...
    TypeError: can't compare offset-naive and offset-aware datetimes
    

    यदि आप इस त्रुटि का सामना करते हैं, तो संभवत: आपका कोड इन दो चीजों की तुलना कर रहा है:

    • Django द्वारा प्रदान किया गया एक जीवनकाल - उदाहरण के लिए, फॉर्म या मॉडल फ़ील्ड से पढ़ा गया मान। चूंकि आपने समय क्षेत्र समर्थन सक्षम किया है, इसलिए यह जागरूक है।
    • आपके कोड द्वारा जनरेट किया गया एक डेटाइम, जो भोला है (या आप इसे नहीं पढ़ रहे हैं)।

    आम तौर पर, सही समाधान यह है कि आप अपने कोड को बदलने के लिए एक जागरूक डेटाटाइम का उपयोग करें।

    यदि आप एक प्लग करने योग्य एप्लिकेशन लिख रहे हैं जो USE_TZ के मूल्य से स्वतंत्र रूप से काम करने की उम्मीद है, तो आप timezone.now() उपयोगी पा सकते हैं। यह फ़ंक्शन USE_TZ = False और USE_TZ = True रूप में एक जागरूक USE_TZ = False रूप में एक भोली USE_TZ = False रूप में वर्तमान दिनांक और समय देता है। आप आवश्यकतानुसार आवश्यकतानुसार timedelta जोड़ या घटा सकते हैं।

  2. मुझे बहुत सारे RuntimeWarning: DateTimeField received a naive datetime दिखाई RuntimeWarning: DateTimeField received a naive datetime (YYYY-MM-DD HH:MM:SS) while time zone support is active - क्या यह बुरा है?

    जब समय क्षेत्र समर्थन सक्षम होता है, डेटाबेस परत को आपके कोड से केवल जागरूक डेटासेट प्राप्त करने की उम्मीद होती है। यह चेतावनी तब होती है जब यह एक भोली उम्र प्राप्त करता है। यह इंगित करता है कि आपने समय क्षेत्र समर्थन के लिए अपने कोड को पोर्ट करना समाप्त नहीं किया है। कृपया इस प्रक्रिया के सुझावों के लिए माइग्रेशन गाइड देखें।

    इस बीच, पश्चगामी संगतता के लिए, डेटाइम को डिफ़ॉल्ट समय क्षेत्र में माना जाता है, जो कि आम तौर पर आप क्या उम्मीद करते हैं।

  3. now.date() कल है! (या कल)

    यदि आपने हमेशा अनुभवहीन डेटासेट का उपयोग किया है, तो आप शायद मानते हैं कि आप डेट डेट को इसकी date() विधि कहकर परिवर्तित कर सकते हैं। आप यह भी मानते हैं कि date datetime.datetime तरह बहुत है, सिवाय इसके कि यह कम सटीक है।

    समय क्षेत्र के बारे में जागरूक माहौल में यह सच नहीं है:

    >>> import datetime
    >>> import pytz
    >>> paris_tz = pytz.timezone("Europe/Paris")
    >>> new_york_tz = pytz.timezone("America/New_York")
    >>> paris = paris_tz.localize(datetime.datetime(2012, 3, 3, 1, 30))
    # This is the correct way to convert between time zones with pytz.
    >>> new_york = new_york_tz.normalize(paris.astimezone(new_york_tz))
    >>> paris == new_york, paris.date() == new_york.date()
    (True, False)
    >>> paris - new_york, paris.date() - new_york.date()
    (datetime.timedelta(0), datetime.timedelta(1))
    >>> paris
    datetime.datetime(2012, 3, 3, 1, 30, tzinfo=<DstTzInfo 'Europe/Paris' CET+1:00:00 STD>)
    >>> new_york
    datetime.datetime(2012, 3, 2, 19, 30, tzinfo=<DstTzInfo 'America/New_York' EST-1 day, 19:00:00 STD>)
    

    जैसा कि इस उदाहरण से पता चलता है, उसी डेटाइम की एक अलग तिथि होती है, यह उस समय क्षेत्र पर निर्भर करता है जिसमें यह प्रतिनिधित्व किया जाता है। लेकिन वास्तविक समस्या अधिक मौलिक है।

    एक डेटाइम समय में एक बिंदु का प्रतिनिधित्व करता है । यह निरपेक्ष है: यह किसी भी चीज़ पर निर्भर नहीं करता है। इसके विपरीत, एक तारीख एक कैलेंडरिंग अवधारणा है । यह समय की अवधि है जिसकी सीमा उस समय क्षेत्र पर निर्भर करती है जिसमें तिथि मानी जाती है। जैसा कि आप देख सकते हैं, ये दोनों अवधारणाएं मौलिक रूप से भिन्न हैं, और डेटटाइम को तारीख में परिवर्तित करना नियतात्मक ऑपरेशन नहीं है।

    अभ्यास में इसका क्या मतलब है?

    आम तौर पर, आपको datetime.datetime परिवर्तित करने से बचना चाहिए। उदाहरण के लिए, आप date टेम्पलेट फ़िल्टर का उपयोग केवल डेटटाइम के भाग को दिखाने के लिए कर सकते हैं। यह फ़िल्टर स्वरूपण को वर्तमान समय क्षेत्र में स्वरूपित करने से पहले परिवर्तित कर देगा, जिससे परिणाम सही दिखाई देंगे।

    यदि आपको वास्तव में रूपांतरण स्वयं करने की आवश्यकता है, तो आपको यह सुनिश्चित करना होगा कि डेटाटाइम पहले उपयुक्त समय क्षेत्र में परिवर्तित हो जाए। आमतौर पर, यह वर्तमान समय क्षेत्र होगा:

    >>> from django.utils import timezone
    >>> timezone.activate(pytz.timezone("Asia/Singapore"))
    # For this example, we just set the time zone to Singapore, but here's how
    # you would obtain the current time zone in the general case.
    >>> current_tz = timezone.get_current_timezone()
    # Again, this is the correct way to convert between time zones with pytz.
    >>> local = current_tz.normalize(paris.astimezone(current_tz))
    >>> local
    datetime.datetime(2012, 3, 3, 8, 30, tzinfo=<DstTzInfo 'Asia/Singapore' SGT+8:00:00 STD>)
    >>> local.date()
    datetime.date(2012, 3, 3)
    
  4. मुझे एक त्रुटि मिली " Are time zone definitions for your database installed? "

    यदि आप MySQL का उपयोग कर रहे हैं, तो टाइम ज़ोन परिभाषाओं को लोड करने के निर्देशों के लिए MySQL नोटों का टाइम ज़ोन परिभाषा खंड देखें।

प्रयोग

  1. मेरे पास एक स्ट्रिंग है "2012-02-21 10:28:45" और मुझे पता है कि यह "Europe/Helsinki" समय क्षेत्र में है। मैं उसे एक जागरूक डेटाटाइम में कैसे बदलूं?

    यह वास्तव में pytz के लिए है।

    >>> from django.utils.dateparse import parse_datetime
    >>> naive = parse_datetime("2012-02-21 10:28:45")
    >>> import pytz
    >>> pytz.timezone("Europe/Helsinki").localize(naive, is_dst=None)
    datetime.datetime(2012, 2, 21, 10, 28, 45, tzinfo=<DstTzInfo 'Europe/Helsinki' EET+2:00:00 STD>)
    

    ध्यान दें कि localize datetime.tzinfo API के लिए एक pytz एक्सटेंशन है। इसके अलावा, आप pytz.InvalidTimeError को पकड़ना चाहते हैं। Pytz के प्रलेखन में और अधिक उदाहरण हैं । जागरूक डेटासेट में हेरफेर करने का प्रयास करने से पहले आपको इसकी समीक्षा करनी चाहिए।

  2. मैं वर्तमान समय क्षेत्र में स्थानीय समय कैसे प्राप्त कर सकता हूं?

    खैर, पहला सवाल यह है कि क्या आपको वास्तव में इसकी आवश्यकता है?

    जब आप मनुष्यों के साथ बातचीत कर रहे हों, तब आपको केवल स्थानीय समय का उपयोग करना चाहिए, और टेम्पलेट परत आपकी पसंद के समय क्षेत्र में डेटाटाइम को बदलने के लिए फ़िल्टर और टैग प्रदान करती है।

    इसके अलावा, पायथन को पता है कि जागरूक डेटासेट की तुलना कैसे की जाती है, जब आवश्यक हो तो यूटीसी ऑफ़सेट्स को ध्यान में रखते हुए। यूटीसी में अपने सभी मॉडल और व्यू कोड लिखना बहुत आसान (और संभवतः तेज) है। इसलिए, अधिकांश परिस्थितियों में, UTC में timezone.now() द्वारा लौटा पर्याप्त होगा।

    पूर्णता के लिए, हालाँकि, यदि आप वर्तमान समय क्षेत्र में स्थानीय समय चाहते हैं, तो यहां बताया गया है कि आप इसे कैसे प्राप्त कर सकते हैं:

    >>> from django.utils import timezone
    >>> timezone.localtime(timezone.now())
    datetime.datetime(2012, 3, 3, 20, 10, 53, 873365, tzinfo=<DstTzInfo 'Europe/Paris' CET+1:00:00 STD>)
    

    इस उदाहरण में, वर्तमान समय क्षेत्र "Europe/Paris"

  3. मैं सभी उपलब्ध समय क्षेत्र कैसे देख सकता हूं?

    pytz helpers प्रदान करता है, जिसमें वर्तमान समय क्षेत्रों की सूची और सभी उपलब्ध समय क्षेत्रों की सूची शामिल है - जिनमें से कुछ केवल ऐतिहासिक हित के हैं।