केवल-तारीख वाले प्रकाशन मान को कैलेंडर तारीख के रूप में पार्स करके और उस तारीख को प्रामाणिक बनाए रखकर सुरक्षित रखें। यदि किसी निर्यात के लिए UTC टाइमस्टैम्प आवश्यक हो, तो UTC-मध्यरात्रि की स्पष्ट परंपरा अपनाएँ। Mac Terminal की यह चरण-दर-चरण मार्गदर्शिका इस अंतर को दिखाती है और राउंड ट्रिप की जाँच करती है।

तय करें कि प्रकाशन फ़ील्ड का वास्तविक अर्थ क्या है

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

इन चार अवधारणाओं की भूमिकाएँ अलग-अलग हैं:

अवधारणा सिंथेटिक उदाहरण अर्थ
नागरिक तारीख 2028-06-15 कैलेंडर का एक दिन, बिना समय या ऑफ़सेट के
क्षण 2028-06-15T00:00:00+00:00 UTC में व्यक्त एक विशिष्ट क्षण
UTC ऑफ़सेट +09:00 स्थानीय घड़ी के समय और UTC के बीच का अंतर
नामित समय क्षेत्र America/Los_Angeles लागू समय-क्षेत्र नियम प्राप्त करने के लिए उपयोग किया जाने वाला पहचानकर्ता

RFC 3339, full-date को date-time से अलग परिभाषित करता है; इसके टाइमस्टैम्प व्याकरण में तारीख के साथ समय और ऑफ़सेट भी शामिल होते हैं। इसलिए, केवल तारीख में प्रकाशन का क्षण पहचानने के लिए आवश्यक जानकारी नहीं होती। मध्यरात्रि चुनने से ऐसी जानकारी जुड़ जाती है जो इनपुट में थी ही नहीं। RFC 3339, section 5.6

नामित समय क्षेत्र में भी एक संख्यात्मक ऑफ़सेट से अधिक जानकारी होती है। Python का zoneinfo दस्तावेज़ दिखाता है कि डेलाइट सेविंग के बदलाव के दौरान किसी समय क्षेत्र के ऑफ़सेट अलग-अलग हो सकते हैं। केवल-तारीख वाले लेबल के लिए इन नियमों का निर्धारण करने की आवश्यकता नहीं है। Python: IANA समय क्षेत्र समर्थन

निर्यात करने से पहले यह निर्णय नियम अपनाएँ:

  • फ़ील्ड का अर्थ है “इस दिन प्रकाशित”: संग्रहण और प्रदर्शन, दोनों में केवल-तारीख वाला मान बनाए रखें।
  • प्राप्तकर्ता फ़ॉर्मैट में टाइमस्टैम्प आवश्यक है: तारीख बनाए रखें और दस्तावेज़ित परंपरा के अनुसार UTC-मध्यरात्रि का वाहक मान निकालें।
  • फ़ील्ड का अर्थ है “इस क्षण प्रकाशित”: वास्तविक समय और ऑफ़सेट, या वह समय और नामित समय क्षेत्र प्राप्त करें जिनसे उस क्षण का निर्धारण हो सके।

वाहक मान की परंपरा अनुकूलता के लिए उपयोगी है, लेकिन इससे अज्ञात प्रकाशन समय का पता नहीं चलता। utc_carrier जैसा फ़ील्ड नाम इस सीमा को स्पष्ट करता है; इसे published_at कहना ऐसी जानकारी का संकेत देगा जो स्रोत ने कभी दी ही नहीं।

समझें कि पिछली तारीख की त्रुटि कहाँ आती है

2028-06-15 के लिए दो संभावित प्रोसेसिंग मार्गों पर विचार करें। पहले मार्ग में, कोई प्रोग्राम निश्चित ऑफ़सेट +09:00 पर मध्यरात्रि गढ़ता है, फिर उस क्षण को UTC में बदलता है। परिणाम 2028-06-14T15:00:00+00:00 होता है: नौ घंटे घटाने पर तारीख बदल जाती है।

दूसरे मार्ग में, प्रोग्राम जानबूझकर UTC में मध्यरात्रि बनाता है: 2028-06-15T00:00:00+00:00। उसी क्षण को निश्चित ऑफ़सेट -07:00 पर दिखाने से 2028-06-14T17:00:00-07:00 मिलता है। ये उदाहरणार्थ ऑफ़सेट गणनाएँ हैं, उस तारीख पर किसी नामित समय क्षेत्र के ऑफ़सेट के दावे नहीं।

दोनों गणनाएँ अपने-अपने क्षण सुरक्षित रखती हैं। इनमें से कोई भी हर रेंडरिंग समय क्षेत्र में मूल कैलेंडर लेबल सुरक्षित नहीं रखती। Python दस्तावेज़ बताता है कि astimezone() घड़ी के फ़ील्ड बदलता है, जबकि व्यक्त UTC समय को सुरक्षित रखता है। Python: datetime.astimezone()

व्यावहारिक रूप से, पार्सिंग और रेंडरिंग के लिए एक साझा अनुबंध होना चाहिए। यदि किसी तारीख को UTC-मध्यरात्रि के वाहक मान में बदला गया है, तो उसके कैलेंडर फ़ील्ड UTC में वापस प्राप्त करें। यदि आप चाहते हैं कि निर्यात कोई भी खोले, तब भी प्रकाशन लेबल वही रहे, तो सुरक्षित रखी गई नागरिक तारीख प्रदर्शित करें।

यह न मानें कि हर भाषा समान अनुपस्थित जानकारी अपने आप भरती है। ECMAScript के अनुसार, ऑफ़सेट के बिना तारीख वाले रूपों को UTC और ऑफ़सेट के बिना तारीख-समय वाले रूपों को स्थानीय समय के रूप में समझा जाता है। इसलिए, किसी स्ट्रिंग में T00:00:00 जोड़ने से JavaScript में उसकी व्याख्या बदल सकती है। ECMAScript: Date.parse

Mac Terminal में प्रकाशन-तारीख की पूरी जाँच करें

यह मार्गदर्शिका तीन सिंथेटिक तारीखों की पुष्टि करती है, टैब से अलग किया गया पूर्वावलोकन प्रिंट करती है और विकृत इनपुट को अस्वीकार करने की जाँच करती है। यह प्रकाशन सूची में बदलाव नहीं करती और न ही कोई निर्यात फ़ाइल बनाती है।

Finder में /Applications/Utilities खोलें, फिर Terminal पर डबल-क्लिक करें। Apple इसे कमांड-लाइन ऐप खोलने का समर्थित तरीका बताता है। Apple: Mac पर Terminal खोलें या बंद करें

अपने इंटरप्रेटर की जाँच के लिए यह कमांड चलाएँ:

python3 --version

इस मार्गदर्शिका के लिए Python 3.11 या बाद का संस्करण इस्तेमाल करें। यदि python3 उपलब्ध नहीं है या पुराना संस्करण दिखाता है, तो आगे बढ़ने से पहले macOS के लिए आधिकारिक इंस्टॉलेशन निर्देशों का पालन करें; फिर Terminal दोबारा खोलें और फिर से जाँचें। Python के दस्तावेज़ macOS इंस्टॉलर और python3 से स्क्रिप्ट चलाने, दोनों के बारे में बताते हैं। Python: macOS पर Python का उपयोग

नीचे दिया गया पूरा ब्लॉक, अंतिम PY सहित, पेस्ट करें और Return दबाएँ। - आर्ग्युमेंट Python को मानक इनपुट से अपना प्रोग्राम पढ़ने के लिए कहता है। सभी नमूना डेटा और इंपोर्ट शामिल हैं। Python: कमांड लाइन और परिवेश

python3 - <<'PY'
import re
from datetime import date, datetime, time, timezone


def parse_publication_date(text):
    if not isinstance(text, str) or re.fullmatch(
        r"[0-9]{4}-[0-9]{2}-[0-9]{2}", text
    ) is None:
        raise ValueError("Expected YYYY-MM-DD")
    return date.fromisoformat(text)


def utc_carrier(day):
    return datetime.combine(day, time(0), tzinfo=timezone.utc)


samples = ["2028-02-29", "2028-06-15", "2028-12-31"]
parsed = [(text, parse_publication_date(text)) for text in samples]

print("publication_date\tutc_carrier")
for original, day in parsed:
    carrier = utc_carrier(day)
    assert day.isoformat() == original
    assert carrier.astimezone(timezone.utc).date() == day
    print(day.isoformat(), carrier.isoformat(timespec="seconds"), sep="\t")

for invalid in [
    "2027-02-29",
    "2028-6-15",
    "2028-06-15T00:00:00",
    " 2028-06-15",
]:
    try:
        parse_publication_date(invalid)
    except ValueError:
        pass
    else:
        raise AssertionError(f"Unexpected acceptance: {invalid!r}")

print("Round-trip and rejection checks passed.")
PY

अपेक्षित आउटपुट यह है:

publication_date	utc_carrier
2028-02-29	2028-02-29T00:00:00+00:00
2028-06-15	2028-06-15T00:00:00+00:00
2028-12-31	2028-12-31T00:00:00+00:00
Round-trip and rejection checks passed.

उपलब्ध Python इंटरप्रेटर से उदाहरण और दोनों निश्चित-ऑफ़सेट गणनाएँ सफलतापूर्वक चलाई गईं। Mac पर ऐप खोलने और इंटरप्रेटर के निर्देश लिंक किए गए आधिकारिक दस्तावेज़ों पर आधारित हैं।

जानें कि उदाहरण प्रकाशन का दिन कैसे सुरक्षित रखता है

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

रूप की यह स्पष्ट जाँच इसलिए महत्वपूर्ण है क्योंकि date.fromisoformat() अन्य ISO रूपों को भी स्वीकार करता है, जिनमें कॉम्पैक्ट तारीखें और सप्ताह-आधारित तारीखें शामिल हैं। फिर datetime.combine() जानबूझकर मध्यरात्रि और UTC जोड़ता है। Python: तारीख और समय के मूल प्रकार

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

दो राउंड-ट्रिप assertions अनुबंध व्यक्त करते हैं। पहली जाँचती है कि पार्सिंग और तारीख फ़ॉर्मैटिंग से मूल लेबल फिर बनता है। दूसरी जाँचती है कि प्राप्त वाहक मान को UTC में समझने पर वही तारीख मिलती है। दोनों मिलकर उसी सटीक संरक्षण कार्य की जाँच करते हैं, केवल यह नहीं कि कोई टाइमस्टैम्प बनाया जा सकता है या नहीं।

आउटपुट में +00:00 स्पष्ट रूप से इस्तेमाल होता है। RFC 3339 UTC ऑफ़सेट सूचक के रूप में Z की भी अनुमति देता है, लेकिन इनमें से कोई प्रत्यय केवल तारीख में जोड़ने से अनुपस्थित समय घटक नहीं मिलता। केवल-तारीख वाला रूप बनाए रखें या पूरा टाइमस्टैम्प सोच-समझकर बनाएँ। RFC 3339, section 5.6

जाँचें कि निर्यात अब भी तारीख बदल रहा है या नहीं

यदि बाद के पूर्वावलोकन में पिछला दिन दिखता है, तो हर चरण की सीमा पर मान जाँचें। सिंथेटिक मध्य नमूना, 2028-06-15, इस्तेमाल करें, ताकि हर चरण की तुलना एक ज्ञात लेबल से कर सकें।

जाँच बिंदु वाहक परंपरा के अनुसार अपेक्षित मान अंतर क्या बताता है
मूल प्रकाशन फ़ील्ड 2028-06-15 पार्सिंग से पहले इनपुट बदल गया
पाठ के रूप में रेंडर की गई पार्स की गई तारीख 2028-06-15 पार्सिंग या सामान्यीकरण ने लेबल बदल दिया
निकाला गया UTC वाहक मान 2028-06-15T00:00:00+00:00 कोई अलग समय या ऑफ़सेट जोड़ा गया
UTC में वापस प्राप्त तारीख 2028-06-15 रूपांतरण या निष्कर्षण में गलत अनुबंध इस्तेमाल हुआ
पाठक को दिखाया गया प्रकाशन लेबल 2028-06-15 व्यूअर वाहक मान को किसी अन्य समय क्षेत्र में दिखा रहा हो सकता है

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

यदि प्राप्तकर्ता टूल केवल क्षणों का समर्थन करता है और उन्हें हमेशा स्थानीय समय में दिखाता है, तो UTC-मध्यरात्रि की परंपरा अपरिवर्तित तारीख लेबल की गारंटी नहीं दे सकती। अलग केवल-तारीख वाला टेक्स्ट कॉलम सुरक्षित रखें, समर्थित केवल-तारीख फ़ील्ड इस्तेमाल करें, या स्पष्ट UTC फ़ॉर्मैटिंग वाला रेंडरर चुनें। यह सीमा ऊपर दी गई ऑफ़सेट गणनाओं से निकलती है; केवल पार्सर बदलने से यह दूर नहीं होगी।

किसी मौजूदा टाइमस्टैम्प को केवल-तारीख वाला इनपुट भी न मानें। वास्तविक क्षण के लिए, समय क्षेत्र बदलने का अर्थ उसे रूपांतरित करना है। Python इस कार्रवाई को tzinfo को बदलने से अलग बताता है; ऐसा करने पर घड़ी के फ़ील्ड बदले बिना समय-क्षेत्र की जानकारी जोड़ी जाती है। Python: समय-क्षेत्र रूपांतरण का व्यवहार

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

स्रोत