JSON में timestamps के लिए कौन सा फ़ॉर्मैट
मुख्य बात: Epoch numbers और ISO strings के अपने-अपने समझौते हैं, पर असली चीज़ें मिलाने से टूटती हैं। offset के साथ ISO 8601 उपयोग करें, UTC में संग्रहीत करें, उपयोगकर्ता के time zone में render करें।
मुख्य बात: wire पर स्पष्ट offset के साथ ISO 8601 उपयोग करें, UTC को अंत में Z के साथ संग्रहीत करें, और केवल प्रदर्शन के समय बदलें; अगर epoch numbers चुनें, तो seconds बनाम milliseconds को वैश्विक रूप से तय करें और इकाई फ़ील्ड नाम में रखें।
2026-10-30 14:30:00 क्यों काफ़ी नहीं है
उस string में कोई zone नहीं है। Shanghai में 14:30 और London में 14:30 में आठ घंटे का अंतर है, और यह बताने का कोई तरीका नहीं कि कौन सा मतलब है। new Date('2026-10-30 14:30:00') runtime के लोकल zone में parse होता है, इसलिए server और browser एक ही payload से दो अलग क्षण निकालते हैं — वैसी bug जो कभी दोबारा नहीं बनती।
बिना समय वाली 2026-10-30 कोई क्षण ही नहीं है। जन्मदिनों और billing अवधियों के लिए ठीक, creation समय के लिए गलत।
दो काम करने योग्य फ़ॉर्मैट
ISO 8601 strings
{
"createdAt": "2026-10-30T14:30:00+08:00",
"updatedAt": "2026-10-30T06:30:00Z"
}
पढ़ने योग्य, फ़ॉर्मैट एक जैसा होने पर sortable, ज़रूरत हो तो millisecond परिशुद्धता, और स्वयं-वर्णनात्मक।
Epoch numbers
{ "createdAt": 1793519400 }
संक्षिप्त और स्पष्ट, पर अपठनीय, और seconds बनाम milliseconds एक स्थायी ख़तरा है। अगर epochs चुनें, तो इकाई मानकीकृत करें और फ़ील्ड नाम में रखें: createdAtMs createdAt से कहीं अधिक सुरक्षित है।
शुरुआत में तय करने लायक परंपराएँ
| मद | परंपरा |
|---|---|
| Wire फ़ॉर्मैट | Z या +08:00 के साथ ISO 8601 |
| संग्रहण zone | UTC, ताकि DST कभी चित्र में न आए |
| परिशुद्धता | Milliseconds काफ़ी है |
| फ़ील्ड नामकरण | createdAt, updatedAt, expiresAt |
| केवल तारीखें | अलग date फ़ील्ड, जैसे birthday: "1990-01-01" |
| अवधियाँ | Integer और एक इकाई, जैसे timeoutMs: 3000 |
Rendering
new Intl.DateTimeFormat('en-GB', {
dateStyle: 'medium',
timeStyle: 'short',
timeZone: 'Europe/London',
}).format(new Date('2026-10-30T06:30:00Z'));
जब प्रदर्शन device के अनुसार न चलना चाहिए तब timeZone स्पष्ट बताएँ। Browser default पर निर्भर रहना उपयोगकर्ता-सम्मुख समयों के लिए सही और रिपोर्ट्स के लिए गलत है।
तीन बार-बार होने वाली bugs
बिना समय वाली तारीखें UTC मध्यरात्रि के रूप में parse होती हैं। ECMAScript spec के अनुसार, केवल-तारीख strings UTC हैं जबकि date-time strings लोकल। यह असंगति एक दिन आगे-पीछे की bugs का भरोसेमंद स्रोत है।
डेटाबेस का zone serializer से मेल नहीं खाता। MySQL datetime में zone नहीं होता; लोकल लिखें, UTC पढ़ें, तो सब कुछ offset से खिसक जाता है।
Daylight saving। भविष्य के लोकल समय संग्रहीत करने से ऐसे क्षण बनते हैं जो मौजूद नहीं हैं या दो बार आते हैं। UTC में ऐसे अंतराल नहीं होते।
FAQ
ISO 8601 और epoch numbers के बीच चुनाव कैसे करूँ?
ISO 8601 तब उपयोग करें जब लोग payload पढ़ते हों, जब lexical sort क्रम चाहिए, या जब मान को अपना zone साथ रखना हो; कीमत लगभग दर्जन भर अतिरिक्त bytes और एक parsing लाइब्रेरी है। Epoch numbers तब उपयोग करें जब संक्षिप्तता और आसान cross-language handling अधिक मायने रखें, पर seconds बनाम milliseconds वैश्विक रूप से तय करें और बताएँ कि फ़ील्ड में कौन सी इकाई है।
क्या बिना समय वाली तारीख और timestamp एक ही फ़ील्ड साझा कर सकते हैं?
नहीं। बिना समय वाली 2026-10-30 एक calendar दिन है जिसमें न समय है न zone, जबकि timestamp फ़ील्ड से सटीक क्षण अपेक्षित है। जन्मदिन और billing अवधियाँ अलग date फ़ील्ड में रखें, और creation या update समयों के लिए ISO 8601 At फ़ील्ड उपयोग करें।