JavaScript में समय स्वरूपण और रूपांतरण: आम गलतियाँ

JavaScript में समय के साथ अक्सर क्या गलत होता है

JavaScript समय से जुड़ी बग्स अक्सर सीधे "घड़ी गलत है" जैसी नहीं दिखतीं। वे छोटे-छोटे विचलनों के रूप में आती हैं: आपकी मशीन पर सही तारीख सहकर्मी की मशीन पर गलत दिखना, एक API प्रतिक्रिया जो ठीक लगती है लेकिन किसी अलग समय क्षेत्र में रेंडर होने पर उलझन पैदा कर देती है, या मौसमी समय बदलने के आसपास "एक कम" वाली रिपोर्ट।

सबसे आम लक्षण

आप आमतौर पर इनमें से एक (या अधिक) नोटिस करेंगे:

• एक घंटे का अंतर: खासकर Daylight Saving Time के आसपास, या जब कोई मान अनजाने में स्थानीय समय और UTC के बीच परिवर्तित हो जाता है।
• एक दिन का अंतर: केवल तारीख वाला मान (जैसे "2025-12-23") समय क्षेत्र के अनुसार पिछले/अगले दिन के रूप में दिख सकता है।
• गलत समय क्षेत्र: समय सही दिखते हैं, लेकिन ऑफ़सेट (उदा., +02:00) आपकी उम्मीद से अलग है।
• असंगत स्वरूपण: "Chrome में काम करता है" पर Safari में अलग दिखना, या सर्वर और ब्राउज़र किसी स्ट्रिंग को पार्स करने में असहमत होना।

ऐसा क्यों होता है: “समय” के अलग मतलब हो सकते हैं

एक बड़ी समस्या यह है कि शब्द समय अलग-अलग अवधारणाओं को दर्शा सकता है:

• एक पल (instant): दुनियाभर में एक विशिष्ट क्षण (उदा., “2025-12-23T10:00:00Z”)। लॉगिंग, इवेंट्स और API स्टोरेज के लिए यह आम तौर पर सही होता है।
• कैलेंडर तिथि: कैलेंडर पर एक दिन बिना किसी समय क्षेत्र के (उदा., जन्मदिन, चालान तिथि)। इसे एक पल की तरह व्यवहार करने पर यह दिन सीमा पार कर सकता है।
• वॉल-क्लॉक समय: "बर्लिन में सुबह 9:00", जो समय क्षेत्र नियमों और DST पर निर्भर करता है।

JavaScript का इन-बिल्ट Date इन सभी को कवर करने की कोशिश करता है, लेकिन यह मुख्यतः एक विश्वव्यापी पल को दर्शाता है और साथ ही आपको स्थानीय प्रदर्शन की ओर धकेलता रहता है, जिससे अनजाने में परिवर्तनों की संभावना बढ़ जाती है।

यह लेख किस पर केंद्रित है

यह मार्गदर्शिका व्यवहारिक है: कैसे ब्राउज़र और सर्वर में पूर्वानुमेय रूपांतरण करें, सुरक्षित प्रारूप (जैसे ISO 8601) कैसे चुनें, और क्लासिक जालें (सेकंड बनाम मिलीसेकंड, UTC बनाम स्थानीय, और पार्सिंग भिन्नताएँ) कैसे पहचानें। लक्ष्य अधिक सिद्धांत नहीं है—बल्कि कम "क्यों यह शिफ्ट हुआ?" के आश्चर्य।

समय डेटा प्रकार: टाइमस्टैम्प, Date, और स्ट्रिंग

JavaScript समय की बग्स अक्सर उन प्रतिनिधित्वों को मिलाने से शुरू होती हैं जो दिखने में आपस में इंटरचेन्ज़ेबल लगते हैं, पर वास्तव में नहीं होते।

आप जो तीन प्रतिनिधित्व सबसे ज्यादा देखेंगे

1) एपॉक मिलीसेकंड (नंबर)

एक सादा नंबर जैसे 1735689600000 आमतौर पर "1970-01-01T00:00:00Z से मिलीसेकंड" होता है। यह एक विश्वव्यापी पल को दर्शाता है जिसमें कोई फॉर्मैटिंग या समय क्षेत्र संलग्न नहीं है।

2) Date ऑब्जेक्ट (एक पल के चारों ओर रैपर)

Date उसी तरह के पल को स्टोर करता है जैसा कि टाइमस्टैम्प करता है। भ्रम पैदा करने वाली बात: जब आप Date को प्रिंट करते हैं, तो JavaScript आपके पर्यावरण के स्थानीय नियमों का उपयोग करके उसे फॉर्मैट करता है जब तक आप अलग से न बताएँ।

3) स्वरूपित स्ट्रिंग (मानव-प्रदर्शन)

"2025-01-01", "01/01/2025 10:00", या "2025-01-01T00:00:00Z" जैसी स्ट्रिंग्स एक जैसी नहीं हैं। कुछ अस्पष्ट नहीं होते (ISO 8601 के साथ Z), कुछ लोकल पर निर्भर करते हैं, और कुछ में समय क्षेत्र शामिल नहीं होता।

“एक पल” बनाम “मानव प्रदर्शन समय”

• एक पल: "यह ठीक यही क्षण वैश्विक रूप से" (सबसे अच्छा स्टोर करना: एपॉक मिलीसेकंड या UTC ISO स्ट्रिंग)।
• मानव प्रदर्शन समय: "उपयोगकर्ता को क्या दिखना चाहिए" (लोकैल और समय क्षेत्र पर निर्भर)।

एक ही पल अलग-अलग समय क्षेत्रों में अलग दिख सकता है:

const instant = new Date("2025-01-01T00:00:00Z");

instant.toLocaleString("en-US", { timeZone: "UTC" });
// "1/1/2025, 12:00:00 AM"

instant.toLocaleString("en-US", { timeZone: "America/Los_Angeles" });
// "12/31/2024, 4:00:00 PM" (पिछला दिन)

एक “स्रोत‑सत्य” चुनें

एक एकल आंतरिक प्रतिनिधित्व चुनें (आम तौर पर एपॉक मिलीसेकंड या UTC ISO 8601) और इसे अपने ऐप और APIs में लगातार उपयोग करें। Date और स्वरूपित स्ट्रिंग्स के बीच रूपांतरण केवल सीमाओं पर करें: इनपुट पार्सिंग और UI प्रदर्शन में।

टाइमस्टैम्प: सेकंड बनाम मिलीसेकंड (आसान मिलाने वाली चीज़)

“टाइमस्टैम्प” आमतौर पर एपॉक समय (Unix time) का मतलब होता है: 1970-01-01 00:00:00 UTC से बीते समय की गिनती। पकड़ यह है कि अलग‑अलग सिस्टम अलग ईकाइयों में गिनते हैं।

JavaScript का Date सबसे ज्यादा भ्रम का स्रोत है क्योंकि यह मिलीसेकंड उपयोग करता है। कई APIs, डेटाबेस, और लॉग्स सेकंड में होते हैं।

अंगूठा नियम

• Unix टाइमस्टैम्प (सेकंड): 1704067200
• JavaScript टाइमस्टैम्प (मिलीसेकंड): 1704067200000

एक ही क्षण, पर मिलीसेकंड वर्ज़न में तीन अतिरिक्त अंक होते हैं।

सुरक्षित रूपांतरण (सेकंड ↔ मिलीसेकंड)

इकाइयाँ स्पष्ट करने के लिए स्पष्ट गुणा/विभाजन का प्रयोग करें:

// seconds -> Date
const seconds = 1704067200;
const d1 = new Date(seconds * 1000);

// milliseconds -> Date
const ms = 1704067200000;
const d2 = new Date(ms);

// Date -> seconds
const secondsOut = Math.floor(d2.getTime() / 1000);

// Date -> milliseconds
const msOut = d2.getTime();

क्लासिक बग: सेकंड को Date() में पास करना

यह दिखने में सही लगता है, लेकिन गलत है जब ts सेकंड में है:

const ts = 1704067200;      // seconds
const d = new Date(ts);     // WRONG: treated as milliseconds

परिणाम 1970 का साल होगा, क्योंकि 1,704,067,200 मिलीसेकंड केवल एपॉक के लगभग 19 दिनों बाद था।

त्वरित सत्यापन और डिबग चेक

जब आप सुनिश्चित न हों कि किस इकाई में है, तो तेज़ गार्डरैस जोड़ें:

function asDateFromUnknownEpoch(x) {
  // crude heuristic: seconds are ~1e9-1e10, milliseconds are ~1e12-1e13
  if (x < 1e11) return new Date(x * 1000); // assume seconds
  return new Date(x);                      // assume milliseconds
}

const input = Number(valueFromApi);
console.log({ input, digits: String(Math.trunc(input)).length });
console.log('as ISO:', asDateFromUnknownEpoch(input).toISOString());

यदि "digits" की गिनती ~10 है, तो संभवतः यह सेकंड हैं। यदि ~13 है, तो मिलीसेकंड हैं। डिबग करते समय toISOString() भी प्रिंट करें: यह अस्पष्ट नहीं है और इकाई की गलती तुरंत दिखने में मदद करता है।

लोकल समय बनाम UTC: आपका आउटपुट क्यों शिफ्ट होता है

JavaScript का Date भ्रमित कर सकता है क्योंकि यह एक ही पल को स्टोर करता है, पर जब आप उस पल को स्थानीय समय (कंप्यूटर/सर्वर सेटिंग्स पर आधारित) बनाम UTC में फॉर्मैट करने के लिए कहते हैं तो वह अलग-अलग तरीके से प्रस्तुत कर सकता है।

आंतरिक रूप से, Date मूलतः "यूनिक्स एपॉक के बाद मिलीसेकंड" होता है। वह संख्या UTC में एक पल का प्रतिनिधित्व करती है। वह "शिफ्ट" तब होती है जब आप उस पल को स्थानीय समय के रूप में फॉर्मैट करना कहें।

लोकल गेटर्स बनाम UTC गेटर्स

कई Date API में लोकल और UTC वैरिएंट दोनों होते हैं। वे एक ही पल के लिए अलग‑अलग संख्याएँ लौटाते हैं:

const d = new Date('2025-01-01T00:30:00Z');

d.getHours();      // hour in *local* time zone
d.getUTCHours();   // hour in UTC

d.toString();      // local time string
d.toISOString();   // UTC (always ends with Z)

अगर आपकी मशीन न्यूयॉर्क (UTC-5) में है, तो वह UTC समय स्थानीय रूप में पिछले दिन का "19:30" दिखा सकता है। एक सर्वर जो UTC पर सेट है वह "00:30" दिखाएगा। एक ही पल, अलग‑अलग प्रदर्शन।

लॉग्स "गलत" क्यों दिखते हैं

लॉग अक्सर Date#toString() का उपयोग करते हैं या Date को इम्प्लिसिटली इंटरपोलेट करते हैं, जो पर्यावरण के लोकल समय क्षेत्र का उपयोग करता है। इसका मतलब है कि एक ही कोड आपके लैपटॉप, CI और प्रोडक्शन पर अलग टाइमस्टैम्प प्रिंट कर सकता है।

व्यावहारिक मार्गदर्शन

समय को UTC में स्टोर और ट्रांसमिट करें (उदा., एपॉक मिलीसेकंड या ISO 8601 के toISOString() से)। डिस्प्ले केवल तभी लोकल में करें जब वह UI के लिए आवश्यक हो:

• APIs के लिए: toISOString() या एपॉक मिलीसेकंड पास करें
• UI के लिए: उपयोगकर्ता के समय क्षेत्र में Intl.DateTimeFormat का उपयोग करके फॉर्मैट करें

अगर आप जल्दी ऐप बना रहे हैं, तो यह अपने जनरेटेड API कॉन्ट्रैक्ट में पहले से ही शामिल कर लें: फ़ील्ड्स को स्पष्ट रूप से नाम दें (createdAtMs, createdAtIso) और सर्वर (Go + PostgreSQL) तथा क्लाइंट (React) दोनों में यह स्पष्ट रखें कि हर फ़ील्ड का क्या प्रतिनिधित्व है।

ISO 8601 स्ट्रिंग्स: APIs के लिए सबसे सुरक्षित फॉर्मेट

अगर आपको ब्राउज़र, सर्वर और डेटाबेस के बीच तारीख/समय भेजना है, तो ISO 8601 स्ट्रिंग्स डिफ़ॉल्ट रूप में सबसे सुरक्षित हैं। वे स्पष्ट हैं, व्यापक रूप से समर्थित हैं, और (सबसे महत्वपूर्ण) समय क्षेत्र की जानकारी साथ लाते हैं।

स्पष्ट UTC या स्पष्ट ऑफ़सेट का उपयोग करें

दो अच्छे इंटरचेंज फॉर्मेट:

• UTC समय (सुझाव: जब लोकल ज़ोन महत्वपूर्ण नहीं हो): 2025-03-04T12:30:00Z
• लोकल समय पर ऑफ़सेट के साथ (जब "लोकल क्लॉक टाइम" मायने रखता हो): 2025-03-04T12:30:00+02:00

"Z" का अर्थ क्या है?

Z का मतलब Zulu time, यानी UTC। तो 2025-03-04T12:30:00Z का अर्थ है "UTC में 12:30"।

+02:00 जैसे ऑफ़सेट कब मायने रखते हैं?

ऑफ़सेट महत्वपूर्ण होते हैं जब कोई इवेंट स्थानीय समय संदर्भ से जुड़ा हो (मुलाकातें, बुकिंग्स, स्टोर खुलने का समय)। 2025-03-04T12:30:00+02:00 वह पल बताता है जो UTC से दो घंटे आगे है, और यह 2025-03-04T12:30:00Z के बराबर नहीं है।

अस्पष्ट डेट स्ट्रिंग्स से बचें

03/04/2025 जैसी स्ट्रिंग्स जाल हैं: क्या यह मार्च 4 है या अप्रैल 3? अलग‑अलग उपयोगकर्ता और पर्यावरण इसे अलग तरीके से इंटरप्रेट करते हैं। 2025-03-04 (ISO तिथि) या पूरा ISO datetime प्राथमिकता दें।

सुरक्षित राउंड‑ट्रिप (string → Date → string)

const iso = "2025-03-04T12:30:00Z";
const d = new Date(iso);
const back = d.toISOString();

console.log(iso);  // 2025-03-04T12:30:00Z
console.log(back); // 2025-03-04T12:30:00.000Z

यह "राउंड‑ट्रिप" व्यवहार API के लिए यही चाहिए: सुसंगत, पूर्वानुमेय और समय क्षेत्र‑सचेत।

पार्सिंग जाल: Date.parse और ब्राउज़र भिन्नताएँ

Date.parse() उपयोगी लगता है: उसे एक स्ट्रिंग दें, एक टाइमस्टैम्प मिल जाता है। समस्या यह है कि ISO 8601 के अलावा किसी भी अनिश्चित फ़ॉर्मेट के लिए पार्सिंग ब्राउज़र हीरिस्टिक्स पर निर्भर कर सकती है। ये हीरिस्टिक्स इंजन और संस्करणों के बीच अलग रही हैं, जिसका मतलब है कि एक ही इनपुट अलग जगहों पर अलग तरीके से पार्स हो सकता है (या नहीं भी हो सकता)।

Date.parse() क्यों भिन्न हो सकता है

JavaScript केवल ISO 8601–स्टाइल स्ट्रिंग्स के लिए पार्सिंग को विश्वसनीय रूप से मानकीकृत करता है (और तब भी, समय क्षेत्र जैसे विस्तार मायने रखते हैं)। "फ्रेंडली" फॉर्मेट्स—जैसे "03/04/2025", "March 4, 2025", या "2025-3-4"—के लिए ब्राउज़र निम्न कर सकते हैं:

• महीने/दिन बनाम दिन/महीना लोकल मान्यताओं पर आधारित
• बिना समय क्षेत्र के स्ट्रिंग्स को एक इंजन में लोकल समय माना जा सकता है, पर दूसरे में रिजेक्ट किया जा सकता है
• थोड़ी गलत स्ट्रिंग्स को "काफी पास" मान लेना… जब तक कि वे न हों

यदि आप सटीक स्ट्रिंग आकार की भविष्यवाणी नहीं कर सकते, तो परिणाम की भविष्यवाणी भी नहीं कर सकते।

आश्चर्यजनक मामला: YYYY-MM-DD

एक सामान्य जाल है "YYYY-MM-DD" (उदा., "2025-01-15") का सरल रूप। कई डेवलपर्स उम्मीद करते हैं कि इसे लोकल मध्यरात्रि के रूप में इंटरप्रेट किया जाएगा। व्यावहारिक रूप से, कुछ पर्यावरण इसे UTC मध्यरात्रि के रूप में मानते हैं।

यह फर्क मायने रखता है: UTC मध्यरात्रि जब लोकल समय में बदली जाती है तो यह नकारात्मक समय क्षेत्रों (उदा., अमेरिका) में पिछला दिन बन सकता है या घंटे बदले हुए दिख सकते हैं। यह "क्यों मेरी तिथि एक दिन अलग है?" वाली बग्स का आसान रास्ता है।

पार्सिंग चेकलिस्ट: उपयोगकर्ता इनपुट बनाम सर्वर इनपुट

सर्वर/API इनपुट के लिए:

• स्पष्ट समय क्षेत्र के साथ पूरा ISO 8601 प्राथमिकता दें, जैसे 2025-01-15T13:45:00Z या 2025-01-15T13:45:00+02:00।
• केवल तिथि वाले मानों को डेटा के रूप में रखें, न कि समय के एक पल के रूप में। अगर यह जन्मदिन या ड्यू तिथि है, तो इसे सपाट स्ट्रिंग ("YYYY-MM-DD") के रूप में रखें और तब तक Date में परिवर्तित न करें जब तक आप इरादा (समय क्षेत्र) न निर्धारित कर लें।

उपयोगकर्ता इनपुट के लिए:

• अस्पष्ट फॉर्मेट्स जैसे 03/04/2025 स्वीकार न करें जब तक आपकी UI अर्थ को बाध्य न करे।
• नियंत्रित इनपुट (डेट पिकर) प्राथमिकता दें जो एक ज्ञात फॉर्मेट उत्पन्न करता है।
• यदि आपको फ्री‑टेक्स्ट पार्स करना है, तो स्वीकृत फॉर्मेट पहले से परिभाषित और लागू करें।

स्पष्ट नियमों का प्रयोग करें (हीरिस्टिक्स नहीं)

Date.parse() पर भरोसा करने की बजाय कि "यह समझ लेगा", इन पैटर्नों में से किसी एक को चुनें:

• सर्वरों से केवल ISO 8601 स्वीकार करें; अन्य को रिजेक्ट करें।
• जानकार फ़ॉर्मेट्स को मैन्युअली पार्स करें (स्ट्रिंग को स्प्लिट करें और लोकल तिथियों के लिए new Date(year, monthIndex, day) का प्रयोग करें)।
• सटीक पलों के लिए टाइमस्टैम्प स्टोर और ट्रांसमिट करें (एपॉक मिलीसेकंड) और डिस्प्ले के समय फॉर्मैट करें।

जब समय डेटा महत्वपूर्ण हो, तो "मेरी मशीन पर पार्स हो गया" पर्याप्त नहीं है—अपने पार्सिंग नियम स्पष्ट और सुसंगत बनाएं।

इंसानों के लिए स्वरूपण: Intl.DateTimeFormat

यदि आपका लक्ष्य "लोगों को उम्मीद के अनुरूप तारीख/समय दिखाना" है, तो JavaScript में सबसे अच्छा टूल Intl.DateTimeFormat है। यह उपयोगकर्ता की लोकैल नियमों (ऑर्डर, विभाजक, महीने के नाम) का उपयोग करता है और month + '/' + day जैसे नाजुक मैन्युअल संयोजन से बचाता है।

यह मैन्युअल स्ट्रिंग निर्माण से क्यों बेहतर है

मैन्युअल फॉर्मैटिंग अक्सर US‑स्टाइल आउटपुट हार्ड‑कोड कर देती है, लीडिंग ज़ीरो भूल जाती है, या 24/12‑घंटे में भ्रम पैदा करती है। Intl.DateTimeFormat यह भी स्पष्ट करता है कि आप किस समय क्षेत्र में दिखा रहे हैं—महत्वपूर्ण जब आपका डेटा UTC में स्टोर है पर UI उपयोगकर्ता के स्थानीय समय को दिखाए।

सामान्य विकल्प जो आप असल में इस्तेमाल करेंगे

"अच्छा दिखाएं" के लिए dateStyle और timeStyle सबसे सरल हैं:

const d = new Date('2025-01-05T16:30:00Z');

// User’s locale + user’s local time zone
console.log(new Intl.DateTimeFormat(undefined, {
  dateStyle: 'medium',
  timeStyle: 'short'
}).format(d));

// Force a specific time zone (great for event times)
console.log(new Intl.DateTimeFormat('en-GB', {
  dateStyle: 'full',
  timeStyle: 'short',
  timeZone: 'UTC'
}).format(d));

यदि आपको निश्चित घंटे‑साइकल चाहिए (उदा., सेटिंग में टॉगल), तो hour12 का उपयोग करें:

console.log(new Intl.DateTimeFormat('en-US', {
  hour: 'numeric',
  minute: '2-digit',
  hour12: true
}).format(d));

एक व्यावहारिक UI पैटर्न

अपनी UI में हर "टाइमस्टैम्प प्रकार" (संदेश समय, लॉग एंट्री, इवेंट स्टार्ट) के लिए एक फॉर्मैटिंग फ़ंक्शन चुनें, और timeZone निर्णय जानबूझकर रखें:

• "मेरे लिए कब हुआ" के लिए लोकल समय का उपयोग करें।
• ऑडिट लॉग्स, सर्वर इवेंट्स या क्रॉस‑टीम समन्वय के लिए एक फिक्स्ड ज़ोन (अक्सर UTC) का उपयोग करें।

इससे आपको सुसंगत, लोकैल‑फ्रेंडली आउटपुट मिलता है बिना नाजुक कस्टम फॉर्मैट स्ट्रिंग्स संभालने के।

Daylight Saving Time: छुपा हुआ एक‑घंटे का बग

Daylight Saving Time (DST) वह समय है जब कोई समय зона अपना UTC ऑफ़सेट (आम तौर पर एक घंटा) कुछ विशिष्ट तारीखों पर बदलती है। कठिनाई यह है कि DST केवल ऑफ़सेट नहीं बदलता—यह कुछ स्थानीय समयों के अस्तित्व को बदल देता है।

गायब और दोहराए गए वॉल‑क्लॉक समय

जब घड़ियाँ spring forward करती हैं, कुछ स्थानीय समय मौजूद ही नहीं होते। उदाहरण के लिए, कई क्षेत्रों में घड़ी 01:59 से सीधे 03:00 हो जाती है, इसलिए 02:30 स्थानीय समय “गायब” होता है।

जब घड़ियाँ fall back करती हैं, कुछ स्थानीय समय दो बार होते हैं। उदाहरण के लिए, 01:30 शिफ्ट से पहले और बाद में दो बार हो सकता है, जिसका अर्थ है कि वही वॉल‑क्लॉक समय दो अलग पलों का संदर्भ दे सकता है।

24 घंटे जोड़ना बनाम "कल उसी स्थानीय समय"

DST सीमाओं के आसपास ये बराबर नहीं होते:

• 24 घंटे जोड़ें: "ठीक 24 * 60 * 60 सेकंड बाद"
• कल उसी स्थानीय समय पर: "इस समय क्षेत्र में कल सुबह 9:00"

यदि DST आज रात शुरू होता है, तो "कल सुबह 9:00" केवल 23 घंटे दूर हो सकता है। यदि DST आज रात समाप्त होता है, तो यह 25 घंटे दूर हो सकता है।

// Scenario: schedule “same local time tomorrow”
const d = new Date(2025, 2, 8, 9, 0); // Mar 8, 9:00 local

const plus24h = new Date(d.getTime() + 24 * 60 * 60 * 1000);
const nextDaySameLocal = new Date(d);
nextDaySameLocal.setDate(d.getDate() + 1);

// Around DST, plus24h and nextDaySameLocal can differ by 1 hour.

setHours आपको चकित कर सकता है

यदि आप date.setHours(2, 30, 0, 0) जैसी कोई चीज़ करते हैं किसी "spring forward" दिन पर, तो JavaScript इसे किसी वैध समय (अक्सर 03:30) पर सामान्य कर सकता है, क्योंकि 02:30 स्थानीय समय में मौजूद नहीं है।

सुरक्षित तरीके

• प्रत्यय (elapsed time) के लिए UTC में गणनाएँ करें: एपॉक मिलीसेकंड और UTC मेथड्स का उपयोग करें।
• लोकल शेड्यूलिंग के लिए, इरादे को स्पष्ट रखें: "कल उसी स्थानीय समय" के लिए कैलेंडर ऑपरेशंस (setDate) का उपयोग करें बजाय मिलीसेकंड जोड़ने के।
• APIs के माध्यम से समयों का आदान‑प्रदान करते समय ISO 8601 ऑफ़सेट या Z के साथ प्राथमिकता दें ताकि पल अस्पष्ट न रहे।

अवधि बनाम तिथियाँ: टाइमर के लिए Date का उपयोग न करें

एक आम बग का स्रोत है Date का उपयोग किसी ऐसी चीज़ के प्रतिनिधित्व के लिए जो कैलेंडर क्षण नहीं है।

एक टाइमस्टैम्प जवाब देता है "यह कब हुआ?" (एक विशिष्ट पल जैसे 2025-12-23T10:00:00Z)। एक ड्यूरेशन जवाब देती है "कितनी देर?" (जैसे "3 मिनट 12 सेकंड")। ये अलग अवधारणाएँ हैं, और इन्हें मिलाने से भ्रमित गणित और अप्रत्याशित समय क्षेत्र/DST प्रभाव आते हैं।

अवधि के लिए Date गलत टूल क्यों है

Date हमेशा एपॉक के सापेक्ष एक बिंदु को दर्शाता है। यदि आप "90 सेकंड" को Date के रूप में स्टोर करते हैं, तो आप वास्तव में "1970-01-01 में 90 सेकंड जोड़कर" स्टोर कर रहे हैं, किसी विशेष समय क्षेत्र में। इसे फॉर्मैट करने पर यह अचानक 01:01:30 दिखा सकता है, एक घंटे द्वारा शिफ्ट हो सकता है, या कोई अनचाही तारीख दिखा सकता है।

अवधियों के लिए, सादा नंबर पसंद करें:

• अवधि को सेकंड या मिलीसेकंड में स्टोर करें (एक यूनिट चुनें और उस पर टिकें)।
• संख्याओं के साथ गणित करें।
• केवल अंतिम चरण में डिस्प्ले स्ट्रिंग में बदलें।

सेकंड को HH:mm:ss में बदलना

यहां एक सरल फॉर्मैटर है जो काउंटडाउन टाइमर और मीडिया लंबाई के लिए काम करता है:

function formatHMS(totalSeconds) {
  const s = Math.max(0, Math.floor(totalSeconds));
  const hh = String(Math.floor(s / 3600)).padStart(2, "0");
  const mm = String(Math.floor((s % 3600) / 60)).padStart(2, "0");
  const ss = String(s % 60).padStart(2, "0");
  return `${hh}:${mm}:${ss}`;
}

formatHMS(75);    // "00:01:15" (countdown timer)
formatHMS(5423);  // "01:30:23" (media duration)

यदि आप मिनट से परिवर्तित कर रहे हैं, तो पहले गुणा करें (minutes * 60) और रेंडर करने तक मान को संख्या रखें।

तुलना, सॉर्टिंग, और रेंज बिना आश्चर्य के

जब आप JavaScript में समयों की तुलना करते हैं, तो सबसे सुरक्षित तरीका है संख्याओं की तुलना करना, न कि फॉर्मैटेड टेक्स्ट की। एक Date ऑब्जेक्ट मूलतः एक संख्यात्मक टाइमस्टैम्प (एपॉक मिलीसेकंड) का रैपर है, इसलिए आप चाहते हैं कि तुलना "नंबर बनाम नंबर" हो।

सुरक्षित तुलना (टाइमस्टैम्प बेहतर)

विश्वसनीय तुलना के लिए getTime() (या Date.valueOf() जो वही नंबर लौटाता है) का उपयोग करें:

const a = new Date('2025-01-10T12:00:00Z');
const b = new Date('2025-01-10T12:00:01Z');

if (a.getTime() < b.getTime()) {
  // a is earlier
}

// Also works:
if (+a < +b) {
  // unary + calls valueOf()
}

फॉर्मैटेड स्ट्रिंग्स जैसे "1/10/2025, 12:00 PM" की तुलना करने से बचें—वे लोकैल पर निर्भर होती हैं और सही क्रम में सॉर्ट नहीं होंगी। मुख्य अपवाद वही ISO 8601 स्ट्रिंग्स हैं जो एक ही फॉर्मेट और टाइमज़ोन में हों (उदा., सभी ...Z)—वे लेक्सिकोग्राफिक रूप से सॉर्टेबल होते हैं।

सॉर्टिंग और रेंज द्वारा फ़िल्टर करना

टाइम के आधार पर सॉर्टिंग आसान है यदि आप एपॉक मिलीसेकंड से सॉर्ट करें:

items.sort((x, y) => new Date(x.createdAt).getTime() - new Date(y.createdAt).getTime());

रेंज के भीतर आइटम फ़िल्टर करना भी यही विचार है:

const start = new Date('2025-01-01T00:00:00Z').getTime();
const end   = new Date('2025-02-01T00:00:00Z').getTime();

const inRange = items.filter(i => {
  const t = new Date(i.createdAt).getTime();
  return t >= start && t < end;
});

“दिन की शुरुआत/अंत” (लोकल बनाम UTC)

"दिन की शुरुआत" इस बात पर निर्भर करती है कि आप लोकल समय या UTC का अर्थ रखते हैं:

// Local start/end of day
const d = new Date(2025, 0, 10); // Jan 10 in local time
const localStart = new Date(d.getFullYear(), d.getMonth(), d.getDate(), 0, 0, 0, 0);
const localEnd   = new Date(d.getFullYear(), d.getMonth(), d.getDate(), 23, 59, 59, 999);

// UTC start/end of day
const utcStart = new Date(Date.UTC(2025, 0, 10, 0, 0, 0, 0));
const utcEnd   = new Date(Date.UTC(2025, 0, 10, 23, 59, 59, 999));

एक परिभाषा जल्दी चुनें और अपनी तुलना तथा रेंज लॉजिक में उस पर टिके रहें।

डिबग चेकलिस्ट: समय रूपांतरण बग कैसे डायग्नोज़ करें

समय की बग्स तब तक यादृच्छिक लगती हैं जब तक आप यह निर्धारित न कर लें आपके पास क्या है (टाइमस्टैम्प? स्ट्रिंग? Date?) और कहां शिफ्ट आ रही है (पार्सिंग, समय क्षेत्र रूपांतरण, फॉर्मैटिंग)।

1) एक ही पल के "तीन दृश्य" कैप्चर करें

शुरू करने के लिए उसी मान को तीन अलग तरीकों से लॉग करें। यह जल्दी बताता है कि समस्या सेकंड बनाम मिलीसेकंड है, लोकल बनाम UTC है, या स्ट्रिंग पार्सिंग है।

console.log('raw input:', input);

const d = new Date(input);
console.log('toISOString (UTC):', d.toISOString());
console.log('toString (local):', d.toString());
console.log('timezone offset (min):', d.getTimezoneOffset());

क्या देखें:

• यदि toISOString() बेहद गलत है (उदा., 1970 का वर्ष या बहुत दूर भविष्य), तो शक करें सेकंड बनाम मिलीसेकंड।
• यदि toISOString() सही दिखता है पर toString() "शिफ्ट" है, तो आप लोकल टाइमज़ोन प्रदर्शन देख रहे हैं।
• यदि getTimezoneOffset() तारीख के अनुसार बदलता है, तो आप डेलाइट सेविंग टाइम पार कर रहे हैं।

2) पर्यावरण सत्यापित करें: समय क्षेत्र और लोकैल

कई "मेरी मशीन पर काम कर रहा है" रिपोर्ट केवल अलग‑अलग पर्यावरण डिफ़ॉल्ट्स होते हैं।

• ब्राउज़र: OS समय क्षेत्र सेटिंग्स और ब्राउज़र भाषा जांचें। फिर लॉग करें:

console.log(Intl.DateTimeFormat().resolvedOptions());

• Node.js / सर्वर: प्रोसेस का समय क्षेत्र सत्यापित करें:

console.log('TZ:', process.env.TZ);
console.log(Intl.DateTimeFormat().resolvedOptions().timeZone);

यदि आपका सर्वर UTC पर चलता है पर आपका लैपटॉप लोकल ज़ोन पर, तो फॉर्मैटेड आउटपुट अलग होगा जब तक आप स्पष्ट timeZone न पास करें।

3) उन जगहों पर टेस्ट जोड़ें जहाँ समय अक्सर टूटता है

DST सीमाओं और "एज" समयों के आसपास यूनिट टेस्ट बनाएं:

• संबंधित ज़ोन में DST स्विच से एक घंटा पहले और बाद
• महीने/साल के अंत, और 23:30 → 00:30 क्रॉसओवर
• यदि आपका प्रोडक्ट कई समय क्षेत्रों का समर्थन करता है तो कई ज़ोन

यदि आप तेज़ी से इटरेट कर रहे हैं, तो इन्हें अपनी स्कैफ़ोल्डिंग का हिस्सा बना दें। उदाहरण के लिए, React + Go ऐप जनरेट करते समय आप छोटी "टाइम कॉन्ट्रैक्ट" टेस्ट सूट जोड़ सकते हैं (API पेलोड उदाहरण + पार्स/फॉर्मैटिंग आश्वासन) ताकि रेग्रेशन डिप्लॉयमेंट से पहले पकड़े जाएँ।

शिपिंग से पहले त्वरित चेकलिस्ट

• इनपुट का स्पष्ट कॉन्ट्रैक्ट: एपॉक मिलीसेकंड या ऑफ़सेट के साथ ISO 8601।
• "2025-03-02 10:00" जैसी अस्पष्ट स्ट्रिंग्स न हों।
• फॉर्मैटिंग हमेशा locale और (जब आवश्यक हो) timeZone निर्दिष्ट करे।
• आपके लक्षित क्षेत्रों के लिए DST सीमाएँ कवर करने वाले टेस्ट मौजूद हों।

विश्वसनीय समय हैंडलिंग के लिए अनुशंसित पैटर्न

JavaScript में विश्वसनीय समय हैंडलिंग मुख्यतः "स्रोत‑सत्य" चुनने और स्टोरेज से डिस्प्ले तक लगातार रहने के बारे में है।

कुछ सरल बेहतरीन प्रथाएँ

UTC में स्टोर और कंप्यूट करें। उपयोगकर्ता‑फेस के लिए लोकल समय को केवल एक प्रस्तुति विवरण समझें।

सिस्टमों के बीच तारीखों को ISO 8601 स्ट्रिंग्स के साथ स्पष्ट ऑफ़सेट (पसंदीदा Z) के रूप में ट्रांसमिट करें। अगर आपको संख्यात्मक एपॉक्स भेजने हैं, तो यूनिट का दस्तावेज़ीकरण करें और एकरूप रखें (JS में मिलीसेकंड आम डिफ़ॉल्ट है)।

इंसानों के लिए फॉर्मैट करने में Intl.DateTimeFormat (या toLocaleString) का उपयोग करें, और जब आपको निर्णायक आउटपुट चाहिए तो स्पष्ट timeZone पास करें (उदा., हमेशा UTC दिखाना या किसी विशेष व्यावसायिक क्षेत्र को दिखाना)।

निर्णय गाइड: DB बनाम API बनाम UI

• डेटाबेस: एक पल को UTC में स्टोर करें (एपॉक मिलीसेकंड या UTC datetime टाइप)। जब तक आपका डोमेन सचमुच वॉल‑क्लॉक टाइम स्टोर करता हो (जैसे "स्टोर 09:00 पर खुलता है"), लोकल datetimes से बचें।
• API बाउंड्रीज़: Z के साथ ISO 8601 पसंद करें (उदा., 2025-12-23T10:15:00Z)। यदि एपॉक्स का उपयोग कर रहे हैं, तो फ़ील्ड नाम जैसे createdAtMs दें ताकि यूनिट स्पष्ट हो।
• UI: स्टोर किए गए UTC पल को उपयोगकर्ता की लोकैल के लिए फॉर्मैट करें। शेड्यूलिंग UI में समय क्षेत्र को स्पष्ट रूप से लेबल करें और रूपांतरण स्पष्ट रखें।

कब लाइब्रेरी उपयोगी है

अगर आपको recurring events, जटिल समय ज़ोन नियम, DST‑सुरक्षित अंकगणित ("कल उसी स्थानीय समय"), या असंगत इनपुट्स से बहुत पार्सिंग करनी है तो समर्पित डेट‑टाइम लाइब्रेरी पर विचार करें। मूल्य स्पष्ट APIs और कम एज‑केस बग्स में है।

अगर आप अधिक गहराई में जाना चाहते हैं, तो /blog पर और समय‑संबंधी मार्गदर्शिकाएँ पढ़ें। यदि आप टूलिंग या सपोर्ट विकल्पों का मूल्यांकन कर रहे हैं, तो देखें /pricing।