JavaScript ਸਮਾਂ ਫਾਰਮੈਟਿੰਗ ਅਤੇ ਕਨਵਰਜਨ: ਆਮ ਗਲਤੀਆਂ

JavaScript ਵਿੱਚ ਸਮੇਂ ਦੀ ਫਾਰਮੈਟਿੰਗ ਅਤੇ ਕਨਵਰਜਨ — ਆਮ ਗਲਤੀਆਂ

JavaScript ਦੇ ਸਮੇਂ ਨਾਲ ਸਬੰਧਤ ਬੱਗ ਆਮ ਤੌਰ 'ਤੇ "ਘੜੀ ਗਲਤ ਹੈ" ਵਰਗੇ ਨਹੀਂ ਹੁੰਦੇ। ਉਹ ਪ੍ਰਾਈਵੇਟ ਝਟਕਿਆਂ ਵਾਂਗ ਆਉਂਦੇ ਹਨ: ਇਕ ਤਾਰੀਖ ਜੋ ਤੁਹਾਡੇ ਲੈਪਟਾਪ 'ਤੇ ਸਹੀ ਲੱਗਦੀ ਹੈ ਪਰ ਸਹਿਯੋਗੀ ਦੀ ਮਸ਼ੀਨ 'ਤੇ ਗਲਤ, ਕੋਈ API ਜਵਾਬ ਜੋ ਇੱਕ ਟਾਈਮਜ਼ੋਨ ਵਿੱਚ ਠੀਕ ਲੱਗਦਾ ਹੈ ਪਰ ਦੂਜੇ ਵਿੱਚ ਗੜਬੜ ਕਰ ਦਿੰਦਾ ਹੈ, ਜਾਂ ਮੌਸਮੀ ਬਦਲਾਅ ਦੇ ਆਲੇ-ਦੁਆਲੇ "ਇੱਕ ਘੰਟੇ ਜਾਂ ਇੱਕ ਦਿਨ ਦੀ ਗਲਤੀ"।

ਸਭ ਤੋਂ ਆਮ ਲੱਛਣ

ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਜਾਂ ਹੋਰ ਨੋਟਿਸ ਕਰੋਗੇ:

• ਇੱਕ ਘੰਟੇ ਦੀ ਗਲਤੀ: ਖ਼ਾਸ ਕਰਕੇ Daylight Saving Time (DST) ਦੇ ਆਲੇ-ਦੁਆਲੇ, ਜਾਂ ਜਦੋਂ ਨਹੀਂ ਜਾਣ ਕੇ ਸਥਾਨਕ ਸਮਾਂ ਅਤੇ UTC ਦੇ ਵਿਚਕਾਰ কਨਵਰਟ ਹੋ ਜਾਂਦਾ ਹੈ।
• ਇੱਕ ਦਿਨ ਦੀ ਗਲਤੀ: date-only ਵੈਲਯੂ (ਜਿਵੇਂ "2025-12-23") ਟਾਈਮਜ਼ੋਨ 'ਤੇ ਨਿਰਭਰ ਕਰਕੇ ਪਿਛਲਾ/ਅਗਲਾ ਦਿਨ ਦਿਖਾ ਸਕਦੀ ਹੈ।
• ਗਲਤ ਟਾਈਮਜ਼ੋਨ: ਸਮਾਂ ਸਹੀ ਲੱਗਦਾ ਹੈ, ਪਰ offset (ਉਦਾਹਰਣ ਵਜੋਂ +02:00) ਉਮੀਦ ਦੇ ਮੁਤਾਬਕ ਨਹੀਂ।
• ਅਸਮਰਥ ਫਾਰਮੈਟਿੰਗ: "Chrome ਵਿੱਚ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ" ਪਰ Safari ਵਿੱਚ ਵੱਖਰਾ ਦਿਖਦਾ ਹੈ, ਜਾਂ ਸਰਵਰ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਇੱਕ ਸਤਰ ਨੂੰ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਨਾਲ parse ਕਰਦੇ ਹਨ।

ਇਹ ਕਿਉਂ ਹੁੰਦਾ ਹੈ: "ਸਮਾਂ" ਵੱਖ-ਵੱਖ ਮਤਲਬ ਰੱਖ ਸਕਦਾ ਹੈ

ਇੱਕ ਵੱਡੀ ਮੁਸ਼ਕਲ ਇਹ ਹੈ ਕਿ ਸ਼ਬਦ ਸਮਾਂ ਵੱਖ-ਵੱਖ ਸੰਕਲਪਾਂ ਨੂੰ ਦਰਸਾ ਸਕਦਾ ਹੈ:

• ਇੱਕ instant (ਪਲ): ਦੁਨੀਆ ਭਰ ਵਿੱਚ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਲਹਿਰ (ਉਦਾਹਰਣ: “2025-12-23T10:00:00Z”). ਲੌਗਿੰਗ, ਇਵੈਂਟਸ ਅਤੇ API ਸਟੋਰੇਜ ਲਈ ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਚਾਹੀਦਾ ਹੁੰਦਾ ਹੈ।
• ਕੈਲੰਡਰ ਦੀ ਤਾਰੀਖ: ਦਿਨ ਬਿਨਾਂ ਕਿਸੇ ਟਾਈਮਜ਼ੋਨ ਦੇ (ਜਿਵੇਂ ਜਨਮਤਾਰੀਖ, ਇਨਵੌਇਸ ਦੀ ਤਾਰੀਖ)। ਇਸਨੂੰ instant ਵਾਂਗ سمجھਣਾ ਦਿਨ-ਬਦਲੀ ਵਲ ਝਕਾਉ ਕਰ ਸਕਦਾ ਹੈ।
• ਵਾਲ-ਕਲੌਕ ਸਮਾਂ: "ਬਰਲਿਨ ਵਿੱਚ ਸਵੇਰੇ 9:00", ਜੋ ਟਾਈਮਜ਼ੋਨ ਨਿਯਮਾਂ ਅਤੇ DST ਬਦਲਾਅ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।

JavaScript ਦਾ ਬਿਲਟ-ਇਨ Date ਇਹਨਾਂ ਸਭ ਨੂੰ ਕਵਰ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਮੁੱਖ ਰੂਪ ਨਾਲ ਇੱਕ instant ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਅਤੇ ਵੇਖਾਉਣ ਲਈ ਮੁੱਖਤੌਰ 'ਤੇ ਲੋਕਲ ਪ੍ਰਦਰਸਨ ਵੱਲ ਧਿਆਨ ਦਿੰਦਾ, ਜੋ ਅਚਾਨਕ ਕਨਵਰਜਨਾਂ ਨੂੰ ਆਸਾਨ ਬਣਾ ਦਿੰਦਾ ਹੈ।

ਇਹ ਲੇਖ ਕਿਸ 'ਤੇ ਧਿਆਨ ਦੇਂਦਾ ਹੈ

ਇਹ ਗਾਈਡ ਅਮਲੀ ਹੈ: ਕਿਸ ਤਰ੍ਹਾਂ ਬ੍ਰਾਉਜ਼ਰਾਂ ਅਤੇ ਸਰਵਰਾਂ ਵਿੱਚ ਭਰੋਸੇਯੋਗ ਕਨਵਰਜਨ ਪ੍ਰਾਪਤ ਕਰਨੇ ਹਨ, ਕਿਹੜੇ ਫਾਰਮੈਟ (ISO 8601 ਵਰਗੇ) ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਹਨ, ਅਤੇ ਕਲਾਸਿਕ ਫ਼ੈਲਤੀਆਂ (ਸੈਕੰਡ vs ਮਿਲੀਸੈਕੰਡ, UTC vs ਲੋੱਕਲ, parsing ਦੇ ਫਰਕ) ਕਿਵੇਂ ਪਛਾਣੇ ਜਾਣ। ਹੇਠਾਂ ਮਕਸਦ ਘੱਟ ਸਿਧਾਂਤ ਨਹੀਂ—ਪਰ ਘੱਟ "ਕਿਉਂ ਇਹ ਸਰਕ ਗਿਆ?" ਹੈਰਾਨੀਆਂ ਹਨ।

ਸਮਾਂ ਦੇ ਡਾਟਾ ਟਾਈਪ: Timestamp, Date ਅਤੇ String

JavaScript ਦੇ ਸਮੇਂ ਨਾਲ ਜੁੜੀਆਂ ਗਲਤੀਆਂ ਅਕਸਰ ਉਨ੍ਹਾਂ ਅਤੇ ਪ੍ਰਤੀਨਿਧਤਾਵਾਂ ਦੇ ਮਿਲਾਵਟ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਬਾਹਰੋਂ ਇਕੋ ਵਰਗੀ ਲੱਗਦੀਆਂ ਹਨ ਪਰ ਨਹੀਂ ਹੁੰਦੀਆਂ।

ਉਹ ਤਿੰਨ ਪ੍ਰਤੀਨਿਧੀ ਜੋ ਤੁਸੀਂ ਅਕਸਰ ਵੇਖੋਗੇ

1) Epoch milliseconds (number)

ਇੱਕ ਸਧਾਰਨ ਨੰਬਰ ਜਿਵੇਂ 1735689600000 ਆਮ ਤੌਰ 'ਤੇ "1970-01-01T00:00:00Z ਤੋਂ ਲੈ ਕੇ milliseconds" ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਇਹ ਇੱਕ instant ਦਰਸਾਉਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਕੋਈ ਫਾਰਮੈਟਿੰਗ ਜਾਂ ਟਾਈਮਜ਼ੋਨ ਜੁੜਿਆ ਨਹੀਂ।

2) Date object (instant ਦਾ wrapper)

Date ਇਕੋ ਕਿਸਮ ਦਾ instant ਸਟੋਰ ਕਰਦਾ ਹੈ ਜਿਵੇਂ timestamp। ਮੁਸ਼ਕਲ ਗੱਲ ਇਹ ਹੈ ਕਿ ਜਦੋਂ ਤੁਸੀਂ Date ਨੂੰ ਪ੍ਰਿੰਟ ਕਰਦੇ ਹੋ, JavaScript اسے ਤੁਹਾਡੇ environment ਦੇ ਲੋਕਲ ਨਿਯਮਾਂ ਅਨੁਸਾਰ ਫਾਰਮੈਟ ਕਰਦਾ ਹੈ ਜਦ ਤੱਕ ਤੁਸੀਂ ਵੱਖ-ਵੱਖ ਨਹੀਂ ਆਗਿਆ ਦਿੰਦੇ।

3) Formatted string (ਮਨੁੱਖੀ ਦਿਖਵਾ)

ਜਿਹੜੀਆਂ ਸਤਰਾਂ ਜਿਵੇਂ "2025-01-01", "01/01/2025 10:00", ਜਾਂ "2025-01-01T00:00:00Z" ਇਕੋ ਨਹੀਂ ਹਨ। ਕੁਝ ਸਪੱਸ਼ਟ ਹਨ (ISO 8601 ਨਾਲ Z), ਹੋਰ locale 'ਤੇ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਕੁਝ ਵਿੱਚ ਟਾਈਮਜ਼ੋਨ ਨਹੀਂ ਹੁੰਦਾ।

“ਇੰਸਟੈਂਟ” ਵਿਰੁੱਧ “ਮਨੁੱਖੀ ਦਿਖਵਾ”

• ਇੰਸਟੈਂਟ: "ਇਹ ਵਿਸ਼ੇਸ਼ ਪਲ ਦੁਨੀਆ ਭਰ ਲਈ" (ਇਹਨੂੰ epoch ms ਜਾਂ UTC ISO ਸਤਰ ਵਜੋਂ ਸਟੋਰ ਕਰਨਾ ਵਧੀਆ ਹੈ)।
• ਮਨੁੱਖੀ ਦਿਖਵਾ: "ਉਹ ਜੋ ਯੂਜ਼ਰ ਨੂੰ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ" (locale ਅਤੇ ਟਾਈਮਜ਼ੋਨ 'ਤੇ ਨਿਰਭਰ)।

ਇੱਕੋ instant ਵੱਖ-ਵੱਖ ਟਾਈਮਜ਼ੋਨ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਦਿਖ ਸਕਦਾ ਹੈ:

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" (ਪਿਛਲਾ ਦਿਨ)

ਇੱਕ “ਸੋਰਸ ਆਫ਼ ਟਰੂਥ” ਚੁਣੋ

ਇੱਕ ਏਕ ਅੰਦਰੂਨੀ ਪ੍ਰਤੀਨਿਧੀ ਚੁਣੋ (ਆਮ ਤੌਰ 'ਤੇ epoch milliseconds ਜਾਂ UTC ISO 8601) ਅਤੇ ਆਪਣੇ ਐਪ ਅਤੇ APIs ਵਿੱਚ ਇਸ ਨੂੰ ਲਗਾਤਾਰ ਵਰਤੋਂ। Date ਅਤੇ ਫਾਰਮੈਟ ਕੀਤੀਆਂ ਸਤਰਾਂ ਨਾਲ ਕੇਵਲ ਬਾਉਂਡਰੀਜ਼ 'ਤੇ ਹੀ ਕਨਵਰਟ ਕਰੋ: input parsing ਅਤੇ UI display ਤੱਕ।

ਟਾਈਮਸਟੈਂਪ: ਸੈਕੰਡ vs ਮਿਲੀਸੈਕੰਡ (ਸੌਖਾ ਗਲਤ ਹੋ ਜਾਣਾ)

“Timestamp” ਆਮ ਤੌਰ 'ਤੇ epoch time (Unix time) ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ: 1970-01-01 00:00:00 UTC ਤੋਂ ਲਾਂਬੇ ਸਮੇਂ ਦੀ ਗਿਣਤੀ। ਮੁਸ਼ਕਿਲ ਇਹ ਹੈ ਕਿ ਵੱਖ-ਵੱਖ ਸਿਸਟਮ ਵੱਖ-ਵੱਖ ਯੂਨਿਟਾਂ ਵਿੱਚ ਗਿਣਤੀ ਕਰਦੇ ਹਨ।

JavaScript ਦਾ Date ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਭੁੱਲਾਂ ਦਾ ਸਰੋਤ ਹੈ ਕਿਉਂਕਿ ਇਹ milliseconds ਵਰਤਦਾ ਹੈ। ਕਈ APIs, ਡੇਟਾਬੇਸ ਅਤੇ ਲਾਗ਼ ਸੈਕੰਡ ਵਿੱਚ ਰੱਖਦੇ ਹਨ।

ਨਿਯਮ ਆਮ ਤੌਰ 'ਤੇ

• Unix timestamp (seconds): 1704067200
• JavaScript timestamp (milliseconds): 1704067200000

ਇਕੋ ਪਲ, ਪਰ milliseconds ਵਾਲੀ ਵੈਰੀਅਂਟ ਵਿੱਚ ਤਿੰਨ ਹੋਰ ਅੰਕ ਹੁੰਦੇ ਹਨ।

ਸੁਰੱਖਿਅਤ ਕਨਵਰਜਨ (seconds ↔ milliseconds)

ਸਪਸ਼ਟ ਗੁਣਾ/ਭਾਗ ਦੀ ਵਰਤੋਂ ਕਰੋ ਤਾਂ ਜੋ ਯੂਨਿਟ ਸਪੱਸ਼ਟ ਹੋਵੇ:

// 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();

ਕਲਾਸਿਕ ਬੱਗ: seconds ਨੂੰ Date() ਵਿੱਚ ਪਾਸ ਕਰਨਾ

ਇਹ ਦਿੱਖਣ ਵਿੱਚ ਠੀਕ ਲੱਗਦਾ ਹੈ, ਪਰ ਜਦੋਂ ts seconds ਵਿੱਚ ਹੋਵੇ ਤਾਂ ਇਹ ਗਲਤ ਹੈ:

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

ਨਤੀਜਾ 1970 ਵਿੱਚ ਦੀ ਤਾਰੀਖ ਹੋਵੇਗੀ, ਕਿਉਂਕਿ 1,704,067,200 milliseconds epoch ਤੋਂ ਸਿਰਫ਼ ਕੁਝ ਦਿਨਾਂ ਬਾਅਦ ਹੁੰਦੇ ਹਨ।

ਤੇਜ਼ ਜ਼ਾਂਚ ਅਤੇ ਡੀਬੱਗ ਚੈੱਕਸ

ਜਦੋਂ ਤੁਹਾਨੂੰ ਯਕੀਨ ਨਾ ਹੋਵੇ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਕਿਹੜਾ ਯੂਨਿਟ ਹੈ, ਤਾਂ ਛੋਟੇ guardrails ਜੋੜੋ:

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 ਹੈ ਤਾਂ ਸੰਭਵਤ: seconds। ਜੇ ~13 ਹੋਵੇ ਤਾਂ milliseconds। ਡੀਬੱਗ ਕਰਨ ਸਮੇਂ toISOString() ਪ੍ਰਿੰਟ ਕਰੋ: ਇਹ ਸਪਸ਼ਟ ਹੈ ਅਤੇ ਯੂਨਿਟ ਗਲਤੀਆਂ ਨੂੰ ਫੌਰਨ ਪਤਾ ਲਗਦਾ ਹੈ।

ਸਥਾਨਕ ਸਮਾਂ vs UTC: ਤੁਹਾਡਾ ਆਉਟਪੁੱਟ ਕਿਉਂ ਵੱਖਰਾ ਹੁੰਦਾ ਹੈ

JavaScript ਦਾ Date ਕਾਫੀ ਭੰਪੜਕਿਦਾਰ ਹੋ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਇੱਕ instant ਸਟੋਰ ਕਰਦਾ ਹੈ, ਪਰ ਉਹੀ instant ਵੱਖ-ਵੱਖ ਟਾਈਮਜ਼ੋਨ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਨਾਲ ਦਿਖਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।

ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ, Date ਅਸਲ ਵਿੱਚ "Unix epoch ਤੋਂ milliseconds" ਹੈ। ਇਹ ਨੰਬਰ ਇੱਕ UTC ਪਲ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਉਸ ਪਲ ਨੂੰ ਲੋਕਲ ਸਮਾਂ (ਕੰਪਿਊਟਰ/ਸਰਵਰ ਦੀ ਸੈਟਿੰਗਾਂ) ਦੇ ਰੂਪ ਵਿੱਚ ਦਿਖਾਉਂਦੇ ਹੋ ਤਾਂ ਹੀ "ਸ਼ਿਫਟ" ਹੁੰਦੀ ਹੈ।

ਲੋਕਲ getters vs UTC getters

ਕਈ Date APIs ਦੋਵੇਂ ਲੋਕਲ ਅਤੇ UTC ਵਰਜਨਾਂ ਦੇ ਨਾਲ ਆਉਂਦੇ ਹਨ। ਇੱਕੋ instant ਲਈ ਇੰਨ੍ਹਾਂ ਦੇ ਨਤੀਜੇ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ:

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)

ਜੇ ਤੁਹਾਡੀ ਮਸ਼ੀਨ New York (UTC-5) ਵਿੱਚ ਹੈ, ਤਾਂ ਉਹ UTC ਸਮਾਂ ਲੋਕਲ ਰੂਪ ਵਿੱਚ ਪਿਛਲੇ ਦਿਨ ਦੀ ਰਾਤ ਵਜੋਂ ਦਿਖ ਸਕਦਾ ਹੈ। ਇਕੋ instant, ਵੱਖਰਾ ਦਿਖਾਵਾ।

ਲੋਗਜ਼ "ਗਲਤ" ਕਿਉਂ ਲੱਗਦੇ ਹਨ

ਲੋਗ ਅਕਸਰ Date#toString() ਜਾਂ implicit date interpolation ਵਰਤਦੇ ਹਨ, ਜੋ environment ਦੇ ਲੋਕਲ ਟਾਈਮਜ਼ੋਨ ਨੂੰ ਵਰਤਦਾ ਹੈ। ਇਸ ਕਰਕੇ ਇਕੋ ਕੋਡ ਤੁਹਾਡੇ ਲੈਪਟਾਪ, CI ਅਤੇ production 'ਚ ਵੱਖ-ਵੱਖ timestamps ਪ੍ਰਿੰਟ ਕਰ ਸਕਦਾ ਹੈ।

ਅਮਲੀ ਸਲਾਹ

ਸਮਾਂ ਨੂੰ UTC ਵਿੱਚ ਸਟੋਰ ਅਤੇ ਟ੍ਰਾਂਸਮਿਟ ਕਰੋ (ਉਦਾਹਰਣ ਲਈ epoch milliseconds ਜਾਂ ISO 8601 toISOString())। UI 'ਤੇ ਦਿਸ਼ਾ-ਨਿਰਦੇਸ਼ ਲਈ ਸਿਰਫ਼ ਯੂਜ਼ਰ ਦੇ ਲੋਕਲ ਟਾਈਮਜ਼ੋਨ ਲਈ ਫਾਰਮੈਟ ਕਰੋ:

• APIs ਲਈ: toISOString() ਜਾਂ epoch milliseconds ਪREFER ਕਰੋ
• UI ਲਈ: Intl.DateTimeFormat ਨਾਲ ਯੂਜ਼ਰ ਦੇ ਟਾਈਮਜ਼ੋਨ ਵਿੱਚ ਫਾਰਮੈਟ ਕਰੋ

ਜੇ ਤੁਸੀਂ ਛੇਤੀ ਐਪ ਬਣਾ ਰਹੇ ਹੋ (ਮਿਸਾਲ ਵਜੋਂ Koder.ai ਵਿੱਚ vibe-coding workflow), ਤਾਂ ਇਹ ਗੱਲਾਂ ਆਪਣੇ generated API contracts ਵਿੱਚ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਜ਼ਾਹਿਰ ਕਰੋ: fields ਨੂੰ ਸਾਫ਼ ਨਾਮ ਦਿਓ (createdAtMs, createdAtIso) ਅਤੇ ਸਰਵਰ (Go + PostgreSQL) ਅਤੇ ਕਲਾਇੰਟ (React) ਨੂੰ ਇਹ ਦੱਸੋ ਕਿ ਹਰ ਫ਼ੀਲਡ ਦਾ ਮਤਲਬ ਕੀ ਹੈ।

ISO 8601 ਸਤਰਾਂ: APIs ਲਈ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਫਾਰਮੈਟ

ਜੇ ਤੁਹਾਨੂੰ ਬਰਾਊਜ਼ਰ, ਸਰਵਰ ਅਤੇ ਡੇਟਾਬੇਸ ਦੇ ਵਿਚਕਾਰ ਤਰੀਖ/ਸਮਾਂ ਭੇਜਣੇ ਹਨ, ਤਾਂ ISO 8601 ਸਤਰਾਂ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਵਧੀਆ ਰਹਿੰਦੀਆਂ ਹਨ। ਉਹ ਸਪਸ਼ਟ ਹਨ, ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਸਪੋਰਟ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ (ਸਭ ਤੋਂ ਮਹਤਵਪੂਰਨ) ਉਹ ਟਾਈਮਜ਼ੋਨ ਜਾਣਕਾਰੀ ਲੈ ਕੇ ਆਉਂਦੀਆਂ ਹਨ।

explicit UTC ਜਾਂ explicit offset ਦੀ ਵਰਤੋਂ ਕਰੋ

ਦੋ ਚੰਗੇ ਇੰਟਰਚੇਂਜ ਫਾਰਮੈਟ:

• UTC ਸਮਾਂ (ਜਦੋਂ ਤੁਸੀਂ ਲੋਕਲ ਜ਼ੋਨ ਦੀ ਪਰਵਾਹ ਨਹੀਂ ਕਰਦੇ): 2025-03-04T12:30:00Z
• ਲੋਕਲ ਸਮਾਂ ਨਾਲ offset (ਜਦੋਂ "ਲੋਕਲ ਘੜੀ ਦਾ ਸਮਾਂ" ਮੈਟਰ ਕਰਦਾ ਹੈ): 2025-03-04T12:30:00+02:00

"Z" ਦਾ ਮਤਲਬ ਕੀ ਹੈ?

Z Zulu time ਲਈ ਹੈ, ਜੋ ਕਿ UTC ਦਾ ਹੀ ਹੋਰ ਨਾਮ ਹੈ। ਤਾਂ 2025-03-04T12:30:00Z ਦਾ ਮਤਲਬ ਹੈ "UTC ਵਿੱਚ 12:30"।

ਜਦੋਂ +02:00 ਵਰਗੇ offsets ਮੈਟਰ ਕਰਦੇ ਹਨ?

Offsets ਉਹ ਵੇਲੇ ਜ਼ਰੂਰੀ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਕੋਈ ਘਟਨਾ ਕਿਸੇ ਲੋਕਲ ਟਾਈਮਜ਼ੋਨ ਨਾਲ ਜੁੜੀ ਹੋਵੇ (ਮੁਲਾਕਾਤਾਂ, ਬੁਕਿੰਗ, ਦੁਕਾਨ ਦਾ ਖੁਲਣ ਸਮਾਂ)। 2025-03-04T12:30:00+02:00 ਇੱਕ ਐਸਾ ਪਲ ਦਰਸਾਉਂਦਾ ਹੈ ਜੋ UTC ਤੋਂ ਦੋ ਘੰਟੇ ਅੱਗੇ ਹੈ, ਅਤੇ ਇਹ 2025-03-04T12:30:00Z ਦੇ ਬਰਾਬਰ ਨਹੀਂ।

ਅੰਬੀਗਿਊਅਸ ਤਾਰੀਖ ਸਤਰਾਂ ਤੋਂ ਦੂਰ ਰਹੋ

03/04/2025 ਵਰਗੀਆਂ ਸਤਰਾਂ ਫੱਸ ਹੋ ਸਕਦੀਆਂ ਹਨ: ਕੀ ਇਹ March 4 ਹੈ ਜਾਂ April 3? ਵੱਖ-ਵੱਖ ਯੂਜ਼ਰ ਅਤੇ ਵਾਤਾਵਰਨ ਇਸਨੂੰ ਵੱਖਰਾ ਸਮਝ ਸਕਦੇ ਹਨ। 2025-03-04 (ISO date) ਜਾਂ ਪੂਰਾ ISO datetime ਵਰਤੋ।

ਸੁਰੱਖਿਅਤ "round-trip" (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 ਲਈ ਇਹ "round-trip" exactly ਉਹੀ ਚਾਹੀਦੀ ਹੈ: consistent, predictable, ਅਤੇ ਟਾਈਮਜ਼ੋਨ–ਅਵੇਅਰ।

Parsing ਦੀਆਂ ਮੁਸ਼ਕਲਾਂ: Date.parse ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਫਰਕ

Date.parse() ਸੁਵਿਧਾਜਨਕ ਲੱਗਦਾ ਹੈ: ਇਕ ਸਤਰ ਦਿਉ, timestamp ਮਿਲ ਜਾਏ। ਮੁਸ਼ਕਿਲ ਇਹ ਹੈ ਕਿ ਜੇ ਇਹ ਸ਼ੁੱਧ ISO 8601 ਨਹੀਂ ਹੈ, ਤਾਂ parsing ਬ੍ਰਾਊਜ਼ਰ heuristics 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਇਹ heuristics ਇੰਜਣ ਅਤੇ ਵਰਜਨਾਂ ਵਿੱਚ ਵੱਖਰੇ ਰਹੇ ਹਨ, ਜਿਸ ਦਾ ਮਤਲਬ ਹੈ ਇਹੀ ਇਨਪੁੱਟ ਵੱਖ-ਵੱਖ ਥਾਂ ਤੇ ਵੱਖ-ਵੱਖ parse ਹੋ ਸਕਦੀ ਹੈ (ਜਾਂ ਨਹੀਂ ਵੀ ਹੋ ਸਕਦੀ)।

Date.parse() ਕਿਉਂ ਵੱਖਰਾ ਹੋ ਸਕਦਾ ਹੈ

JavaScript ਸਿਰਫ਼ ISO 8601–ਸਟਾਈਲ ਸਤਰਾਂ ਲਈ parsing ਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਸਟੈਂਡਰਡ ਕਰਦਾ ਹੈ (ਹਾਲਾਂਕਿ ਟਾਈਮਜ਼ੋਨ ਵਰਗੀਆਂ ਛੋਟੀਆਂ ਬਾਤਾਂ 'ਤੇ ਵੀ ਧਿਆਨ ਚਾਹੀਦਾ ਹੈ)। "ਫ੍ਰੈਂਡਲੀ" ਫਾਰਮੈਟ—ਜਿਵੇਂ "03/04/2025", "March 4, 2025", ਜਾਂ "2025-3-4"—ਬ੍ਰਾਊਜ਼ਰ ਇਹਨੂੰ:

• Month/day vs day/month locale ਧਾਰਣਾਂ ਅਨੁਸਾਰ
• ਬਿਨਾਂ ਟਾਈਮਜ਼ੋਨ ਵਾਲੀਆਂ ਸਤਰਾਂ ਨੂੰ ਇਕ ਇੰਜਣ ਲੋਕਲ ਸਮਾਂ ਮੰਨ ਸਕਦਾ ਹੈ, ਦੂਜਾ reject ਕਰ ਸਕਦਾ ਹੈ
• ਥੋੜੀਆਂ-ਬਹੁਤ ਖਰਾਬ ਸਤਰਾਂ ਨੂੰ "ਕਾਫੀ ਨੇੜੇ" ਸਮਝ ਕੇ parse ਕਰ ਸਕਦਾ ਹੈ… ਜਦੋਂ ਤੱਕ ਉਹ ਨਹੀਂ ਕਰਦਾ

ਜੇ ਤੁਸੀਂ ਸਟਰਿੰਗ ਦੀ ਸ਼ਕਲ ਪੂਰੀ ਤਰ੍ਹਾਂ predict ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ parsing ਦਾ ਨਤੀਜਾ ਵੀ predict ਨਹੀਂ ਹੋ ਸਕਦਾ।

ਹੈਰਾਨੀਜਨਕ ਮਾਮਲਾ: YYYY-MM-DD

ਆਮ ਫਸਲ plain date ਫਾਰਮ "YYYY-MM-DD" (ਉਦਾਹਰਨ ਲਈ "2025-01-15") ਹੈ। ਬਹੁਤ ਸਾਰੇ ਡਿਵੈਲਪਰ ਉਮੀਦ ਕਰਦੇ ਹਨ ਕਿ ਇਹ form ਨੂੰ ਲੋਕਲ midnight ਵਜੋਂ interpret ਕੀਤਾ ਜਾਵੇਗਾ। ਹਕੀਕਤ ਵਿੱਚ, ਕੁਝ ਵਾਤਾਵਰਨ ਇਸਨੂੰ UTC midnight ਵਜੋਂ treat ਕਰਦੇ ਹਨ।

ਇਹ ਫਰਕ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਜੇ UTC midnight ਨੂੰ ਲੋਕਲ ਸਮੇਂ ਵਿੱਚ ਬਦਲਿਆ ਜਾਵੇ ਤਾਂ ਇਹ ਨਕਾਰਾਤਮਕ ਟਾਈਮਜ਼ੋਨ (ਉਦਾਹਰਣ: ਅਮਰੀਕਾ) ਵਿੱਚ ਪਿਛਲੇ ਦਿਨ ਬਣ ਸਕਦਾ ਹੈ ਜਾਂ ਘੰਟੇ ਵਿੱਚ ਅਚਾਨਕ shift ਹੋ ਸਕਦਾ ਹੈ। ਇਹ ਆਸਾਨੀ ਨਾਲ "ਮੇਰੀ ਤਾਰੀਖ ਕਿਉਂ ਇੱਕ ਦਿਨ ਘਟ ਗਈ?" ਬੱਗ ਪੈਦਾ ਕਰਦਾ ਹੈ।

Parsing ਚੈੱਕਲਿਸਟ: ਯੂਜ਼ਰ ਇਨਪੁੱਟ vs ਸਰਵਰ ਇਨਪੁੱਟ

ਸਰਵਰ/API ਇਨਪੁੱਟ ਲਈ:

• ਪੂਰਾ ISO 8601 explicit time zone ਨਾਲ prefer ਕਰੋ, ਜਿਵੇਂ 2025-01-15T13:45:00Z ਜਾਂ 2025-01-15T13:45:00+02:00।
• date-only ਵੈਲਯੂਆਂ ਨੂੰ ਡਾਟਾ ਵਜੋਂ ਹੀ ਰੱਖੋ, ਇੱਕ ਮੋਮੈਂਟ ਵਜੋਂ ਨਹੀਂ। ਜੇ ਇਹ ਜਨਮਦਿਨ ਜਾਂ ਡਿਊ ਡੇਟ ਹੈ, ਤਾਂ ਇਸਨੂੰ plain string ("YYYY-MM-DD") ਵਜੋਂ ਰੱਖੋ ਅਤੇ ਉਸ ਦਾ ਟਾਈਮਜ਼ੋਨ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ ਜੇ ਤੁਸੀਂ Date ਵਿੱਚ convert ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ।

ਯੂਜ਼ਰ ਇਨਪੁੱਟ ਲਈ:

• ambiguous ਫਾਰਮੈਟ ਜਿਵੇਂ 03/04/2025 accept ਨਾ ਕਰੋ ਜਦ ਤੱਕ ਤੁਹਾਡੀ UI ਇਸਦਾ ਮਤਲਬ ਨਿਰਧਾਰਿਤ ਨਾ ਕਰ ਦੇਵੇ।
• controlled inputs (date pickers) ਪ੍ਰਿਫਰ ਕਰੋ ਜੋ ਜਾਣੇ-ਪਛਾਣੇ ਫਾਰਮੈਟ ਪੈਦਾ ਕਰਦੇ ਹਨ।
• ਜੇ free text parse ਕਰਨੀ ਹੀ ਹੈ, ਤਾਂ accepted formats upfront define ਅਤੇ enforce ਕਰੋ।

explicit ਨਿਯਮ ਵਰਤੋਂ (heuristics ਨਾ)

Date.parse() 'ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ बजाय, ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਇਕ pattern ਚੁਣੋ:

• ਕੇਵਲ ISO 8601 ਸਰਵਰ ਤੋਂ accept ਕਰੋ; ਹੋਰ ਸਭ reject ਕਰੋ।
• ਜਾਣੇ-ਪਛਾਣੇ ਫਾਰਮੈਟ ਮੈਨੁਅਲੀ parse ਕਰੋ (string split ਕਰਕੇ ਅਤੇ new Date(year, monthIndex, day) ਵਰਗੇ ਨਿਰਧਾਰਿਤ ਤਰੀਕੇ ਲਓ) ਤਾਂ ਕਿ ਲੋਕਲ dates ਲਈ ਨਤੀਜੇ predictable ਹੋਣ।
• ਸਟੋਰ ਅਤੇ ਟ੍ਰਾਂਸਮਿਟ timestamps (epoch milliseconds) ਠੋਸ ਇੰਸਟੈਂਟਸ ਲਈ, ਅਤੇ ਦਿਖਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਫਾਰਮੈਟ ਕਰੋ।

ਜਦੋਂ ਸਮਾਂ ਡਾਟਾ ਕਰੀਟਿਕਲ ਹੋਵੇ, "ਮੇਰੇ ਮਸ਼ੀਨ ਤੇ parse ਹੁੰਦਾ ਹੈ" ਕਾਫ਼ੀ ਨਹੀਂ—ਤੁਹਾਨੂੰ parsing ਨਿਯਮ explicit ਅਤੇ consistent ਰੱਖਣੇ ਚਾਹੀਦੇ ਹਨ।

ਮਨੁੱਖਾਂ ਲਈ ਫਾਰਮੈਟਿੰਗ: Intl.DateTimeFormat

ਜੇ ਤੁਹਾਡਾ ਟੀਚਾ ਹੈ "ਲੋਕ ਸਮਝਣ ਦੇ ਤਰੀਕੇ ਨਾਲ date/time ਦਿਖਾਉਣਾ", ਤਾਂ JavaScript ਵਿੱਚ ਸਭ ਤੋਂ ਵਧੀਆ ਟੂਲ Intl.DateTimeFormat ਹੈ। ਇਹ ਯੂਜ਼ਰ ਦੇ locale ਨਿਯਮ ਵਰਤਦਾ ਹੈ (ਕ੍ਰਮ, ਸੈਪਰੈਟਰ, ਮਹੀਨੇ ਦੇ ਨਾਮ) ਅਤੇ ਹੱਥੋਂ-ਹੱਥ string ਜੋੜਨ ਦੀ ਨਾਜੁਕ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਟਾਲਦਾ ਹੈ।

ਇਹ ਮੈਨੂਅਲ string building ਤੋਂ ਕਿਉਂ ਬੇਹਤਰ ਹੈ

ਮੈਨੂਅਲ ਫਾਰਮੈਟਿੰਗ ਅਕਸਰ US-ਸਟਾਈਲ ਨਤੀਜੇ hard-code ਕਰ ਦਿੰਦੀ ਹੈ, leading zeros ਭੁੱਲ ਜਾਂਦੇ ਹਨ, ਜਾਂ 24/12-hour confusion ਹੋ ਜਾਂਦੀ ਹੈ। Intl.DateTimeFormat ਇਸ ਗੱਲ ਨੂੰ explicit ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਸ ਟਾਈਮਜ਼ੋਨ ਵਿੱਚ ਦਿਖਾ ਰਹੇ ਹੋ—ਜੋ ਓਹਲਾ ਹੈ ਜਦੋਂ ਤੁਹਾਡਾ ਡਾਟਾ 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));

ਜੇ ਤੁਹਾਨੂੰ consistent hour cycles ਚਾਹੀਦੇ ਹਨ (ਉਦਾਹਰਨ ਲਈ ਇੱਕ settings toggle), ਤਾਂ hour12 ਵਰਤੋਂ:

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

ਇੱਕ ਅਮਲੀ UI ਨੈਰੀਟਿਵ

ਤੁਹਾਡੀ UI ਵਿੱਚ ਹਰ ਇਕ "timestamp type" (message time, log entry, event start) ਲਈ ਇਕ formatting function ਚੁਣੋ, ਅਤੇ timeZone ਦਾ ਫੈਸਲਾ ਇਰਾਦੇ ਨਾਲ ਕਰੋ:

• "ਮੇਰੇ ਲਈ ਕਦੋਂ ਹੋਇਆ" ਲਈ ਲੋਕਲ ਸਮਾਂ ਵਰਤੋਂ।
• audit logs, ਸਰਵਰ events, ਜਾਂ cross-team ਲਿਆਜ਼ ਲਈ ਇੱਕ fixed zone (ਅਕਸਰ UTC) ਵਰਤੋਂ।

ਇਸ ਨਾਲ ਤੁਹਾਨੂੰ consistent, locale-friendly output ਮਿਲੇਗੀ ਬਿਨਾਂ ਕਈ custom format strings ਨੂੰ maintain ਕੀਤੇ।

Daylight Saving Time: ਲੁਕਿਆ ਹੋਇਆ ਇੱਕ-ਘੰਟੇ ਦੀ ਗਲਤੀ

Daylight Saving Time (DST) ਉਹ ਸਮਾਂ ਹੈ ਜਦੋਂ ਇੱਕ ਟਾਈਮਜ਼ੋਨ ਆਪਣੀ UTC offset (ਅਕਸਰ ਇੱਕ ਘੰਟਾ) ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਬਦਲਦਾ ਹੈ। ਮੁਸ਼ਕਲ ਗੱਲ ਇਹ ਹੈ ਕਿ DST ਸਿਰਫ਼ offset ਨਹੀਂ ਬਦਲਦਾ—ਕਈ ਵਾਰੀ ਕੁਝ ਲੋਕਲ ਸਮੇ ਹਨ ਜਿਹਨੇ ਮੌਜੂਦ ਹੀ ਨਹੀਂ ਰਹਿੰਦੇ ਜਾਂ ਦੋ ਵਾਰੀ ਆਉਂਦੇ ਹਨ।

ਮਿਸਿੰਗ ਅਤੇ ਡੁਪ्लੀਕੇਟ ਵਾਲ-ਕਲੌਕ ਸਮੇਂ

ਜਦੋਂ ਘੜੀਆਂ spring forward ਕਰਦੀਆਂ ਹਨ, ਤਦ ਕੁਝ ਲੋਕਲ ਸਮੇਂ ਨਹੀਂ ਹੁੰਦੇ। ਉਦਾਹਰਣ ਲਈ, ਕਈ ਖੇਤਰਾਂ ਵਿੱਚ ਘੜੀ 01:59 ਤੋਂ ਸਿੱਧਾ 03:00 'ਤੇ ਛੱਲਦੀ ਹੈ, ਇਸ ਲਈ 02:30 ਲੋਕਲ ਸਮਾਂ " ਮੌਜੂਦ ਨਹੀਂ "।

ਜਦੋਂ ਘੜੀਆਂ fall back ਕਰਦੀਆਂ ਹਨ, ਤਾਂ ਕੁਝ ਲੋਕਲ ਸਮੇਂ ਦੋ ਵਾਰੀ ਹੁੰਦੇ ਹਨ। ਉਦਾਹਰਣ ਲਈ, 01:30 ਇੱਕ ਵਾਰੀ shift ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਇੱਕ ਵਾਰੀ shift ਤੋਂ ਬਾਅਦ ਹੋ ਸਕਦਾ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਇਕੋ ਵਾਲ-ਕਲੌਕ ਸਮਾਂ ਦੋ ਵੱਖ-ਵੱਖ instants ਨੂੰ ਦਰਸਾ ਸਕਦਾ ਹੈ।

24 ਘੰਟੇ ਜੋੜਣਾ vs "ਅਗਲੇ ਦਿਨ ਉਹੀ ਲੋਕਲ ਸਮਾਂ"

DST ਬਾਰਡਰਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਇਹ ਦੋ ਗੱਲਾਂ ਇੱਕੋ ਨਹੀਂ ਰਹਿੰਦੀਆਂ:

• 24 ਘੰਟੇ ਜੋੜੋ: "ਠੀਕ 24 * 60 * 60 ਸਕੇਂਡ ਬਾਅਦ"
• ਅਗਲਾ ਦਿਨ ਇੱਕੋ ਲੋਕਲ ਸਮਾਂ: "ਇਸ ਟਾਈਮਜ਼ੋਨ ਵਿੱਚ ਕੱਲ੍ਹ ਉਹੀ 9:00 AM"

ਜੇ ਅੱਜ ਰਾਤ DST ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਤਾਂ "ਕੱਲ੍ਹ ਉਹੀ 9:00 AM" ਸਿਰਫ਼ 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 ਇਸਨੂੰ ਇਕ ਵੈਧ ਸਮੇਂ ਤੇ normalize ਕਰ ਸਕਦਾ ਹੈ (ਅਕਸਰ 03:30), ਕਿਉਂਕਿ 02:30 ਲੋਕਲ ਸਮੇਂ ਉੱਥੇ ਮੌਜੂਦ ਨਹੀਂ।

ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ

• ਕੇਲਕੁਲੇਸ਼ਨ UTC ਵਿੱਚ ਕਰੋ ਜੇ ਮਕਸਦ elapsed time (ਮਿਆਦ) ਹੈ: epoch milliseconds ਅਤੇ UTC ਮੈਥਡ ਵਰਤੋਂ।
• ਸਥਾਨਕ ਸ਼ੈਡਿਊਲਿੰਗ ਲਈ, ਆਪਣੇ ਇਰਾਦੇ ਨੂੰ explicit ਰੱਖੋ: "ਅਗਲਾ ਦਿਨ 9:00 local" ਲਈ calendar operations (setDate) ਵਰਤੋਂ ਨਾ ਕਿ milliseconds ਜੋੜਨਾ।
• APIs ਰਾਹੀਂ ਟਾਈਮ ਪਾਸ ਕਰਦਿਆਂ, ISO 8601 ਨਾਲ offset ਜਾਂ Z ਵਰਤੋਂ ਤਾਂ ਕਿ instant ambiguous ਨਾ ਰਹੇ।

ਦੌਰਾਨੇ (Durations) vs ਤਾਰੀਖਾਂ: Timer ਲਈ Date ਨਾ ਵਰਤੋਂ

ਆਮ ਗਲਤੀ ਇਹ ਹੈ ਕਿ Date ਨੂੰ ਉਹਨਾਂ ਚੀਜ਼ਾਂ ਲਈ ਵਰਤਿਆ ਜਾਵੇ ਜੋ ਕੈਲੰਡਰ ਮੋਮੈਂਟ ਨਹੀਂ ਹਨ।

Timestamp ਪੁੱਛਦਾ ਹੈ "ਇਹ ਕਦੋਂ ਹੋਇਆ?" (ਉਦਾਹਰਨ: 2025-12-23T10:00:00Z)। Duration ਪੁੱਛਦਾ ਹੈ "ਕਿੰਨੀ ਲੰਬੀ?" (ਜਿਵੇਂ "3 minutes 12 seconds")। ਇਹ ਦੋਵੇਂ ਵੱਖ-ਵੱਖ ਹਨ, ਅਤੇ ਇਨ੍ਹਾਂ ਨੂੰ ਮਿਲਾ ਦੇਣ ਨਾਲ ਗਣਿਤ ਗੜਬੜ ਅਤੇ ਅਣਚਾਹੇ ਟਾਈਮਜ਼ੋਨ/DST ਪ੍ਰਭਾਵ ਆ ਸਕਦੇ ਹਨ।

ਕਿਉਂ Date duration ਲਈ ਗਲਤ ਟੂਲ ਹੈ

Date ਹਮੇਸ਼ਾ epoch ਦੇ relative ਇਕ ਪੌਇੰਟ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ "90 seconds" ਨੂੰ Date ਵਜੋਂ ਸਟੋਰ ਕਰੋਗੇ, ਤਾਂ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ "1970-01-01 plus 90 seconds" ਹੀ ਸਟੋਰ ਕਰ ਰਹੇ ਹੋ। ਫਾਰਮੈਟ ਕਰਨ 'ਤੇ ਇਹ 01:01:30 ਵਗੈਰਾ ਦਿਖਾ ਸਕਦਾ ਹੈ, ਘੰਟੇ ਨਾਲ ਖਿਸਕ ਸਕਦਾ ਹੈ, ਜਾਂ ਕੋਈ ਅਜਿਹਾ ਦਿਨ ਚੁਣ ਸਕਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਨਹੀਂ ਚਾਹੁੰਦੇ।

Duration ਲਈ, ਸਧਾਰਨ ਨੰਬਰ ਵਰਤੋਂ:

• Durations ਨੂੰ seconds ਜਾਂ milliseconds ਵਜੋਂ ਸਟੋਰ ਕਰੋ (ਇੱਕ ਯੂਨਿਟ ਚੁਣੋ ਅਤੇ ਓਸ ਤੇ ਰਲੋ)।
• ਗਣਿਤ ਨੰਬਰਾ ਨਾਲ ਕਰੋ।
• ਰੇਂਡਰ ਕਰਨ ਵੇਲੇ ਹੀ display string ਬਣਾਓ।

seconds ਨੂੰ HH:mm:ss ਵਿੱਚ ਕਨਵਰਟ ਕਰਨਾ

ਇੱਕ ਸਧਾਰਨ formatter countdown timers ਅਤੇ media lengths ਲਈ:

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 ਤੋਂ ਆ ਰਹੇ ਹੋ, ਤਾਂ ਪਹਿਲਾਂ multiply ਕਰੋ (minutes * 60) ਅਤੇ ਸਿਰਫ਼ render ਤੱਕ ਕਦਰ ਨੂੰ ਨੰਬਰ ਰੱਖੋ।

ਬਿਨਾਂ ਹੈਰਾਨੀ ਦੇ ਤੁਲਨਾ, ਸ਼੍ਰੇਣੀਬੱਧ ਕਰਨਾ ਅਤੇ ਰੇਂਜ

JavaScript ਵਿੱਚ ਸਮੇਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਵੇਲੇ, ਸੁਰੱਖਿਅਤ ਰਾਹ ਇਹ ਹੈ ਕਿ ਤੁਲਨਾ ਨੰਬਰਾਂ ਨਾਲ ਕਰੋ, ਨਾ ਕਿ ਫਾਰਮੈਟ ਕੀਤੀਆਂ strings ਨਾਲ। Date ਵਸ ਇੱਕ numeric timestamp (epoch milliseconds) ਦੇ wrapper ਵਾਂਗ ਹੈ, ਇਸ ਲਈ ਤੁਲਨਾਵਾਂ ਆਖ਼ਰਕਾਰ "number vs number" ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।

ਸੁਰੱਖਿਅਤ ਤੁਲਨਾਵਾਂ (timestamps ਬਿਹਤਰ)

ਵਿਸ਼ਵਾਸਯੋਗ ਤੌਰ 'ਤੇ ਤੁਲਨਾ ਕਰਨ ਲਈ 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()
}

ਫਾਰਮੈਟ ਕੀਤੀਆਂ strings ਜਿਵੇਂ "1/10/2025, 12:00 PM" ਨਾਲ ਤੁਲਨਾ ਕਰਨ ਤੋਂ ਬਚੋ—ਉਹ locale-dependent ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਸਹੀ ਤਰੀਕੇ ਨਾਲ sort ਨਹੀਂ ਕਰਦੀਆਂ। ਇੱਕ ਮਾਸ਼ੂਕ exception ISO 8601 ਸਤਰਾਂ ਹਨ ਜੇ ਉਹ ਇੱਕੋ format ਅਤੇ timezone ਵਿੱਚ ਹਨ (ਜਿਵੇਂ ਸਭ ...Z), ਤਾਂ ਉਹ lexicographically sortable ਹੁੰਦੀਆਂ ਹਨ।

ਸਮੇਂ ਅਨੁਸਾਰ sort ਅਤੇ filter

Time ਅਨੁਸਾਰ sorting ਸਧਾਰਨ ਹੈ ਜੇ ਤੁਸੀਂ epoch milliseconds ਨਾਲ sort ਕਰੋ:

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

ਕਿਸੇ ਰੇਂਜ ਵਿੱਚ filter ਕਰਨ ਦਾ ਤਰੀਕਾ ਵੀ ਇਹੋ ਜਿਹਾ ਹੈ:

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;
});

"Start/end of day" (ਲੋਕਲ vs UTC)

"Start of day" ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਲੋਕਲ ਸਮਾਂ ਜਾਂ 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));

ਸ਼ੁਰੂ ਵਿੱਚ ਇਕ definition ਚੁਣੋ ਅਤੇ comparisons ਅਤੇ range logic 'ਚ ਉਸ ਨੂੰ follow ਕਰੋ।

ਡੀਬੱਗ ਚੈੱਕਲਿਸਟ: ਸਮਾਂ ਕਨਵਰਜਨ ਬੱਗ ਨਿਧਾਰਨ ਕਰਨ ਲਈ

ਸਮਾਂ ਦੀਆਂ ਗਲਤੀਆਂ ਬੇਤੁਕੇ ਮਹਿਸੂਸ ਹੁੰਦੀਆਂ ਹਨ ਜਦ ਤੱਕ ਤੁਸੀਂ ਇਹ ਨੀਠਾ ਨਹੀਂ ਕਰ ਲੈਂਦੇ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਕੀ ਹੈ (timestamp? string? Date?) ਅਤੇ shift ਕਿੱਥੇ ਆ ਰਹੀ ਹੈ (parsing, time zone conversion, formatting)।

1) ਇੱਕੋ ਪਲ ਦੇ "ਤਿੰਨ views" ਲੱਗਾਉ

ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਇਕੋ ਵੈਲਯੂ ਨੂੰ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਨਾਲ ਲੌਗ ਕਰੋ। ਇਹ ਫੌਰਨ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਸਮੱਸਿਆ seconds vs milliseconds ਹੈ, লোকਲ vs UTC ਹੈ, ਜਾਂ string parsing ਦੀ ਗਲਤੀ ਹੈ।

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 ਜਾਂ ਬਹੁਤ ਭਵਿੱਖ), ਤਾਂ seconds vs milliseconds ਦੀ ਸੰਭਾਵਨਾ।
• ਜੇ toISOString() ਠੀਕ ਲੱਗਦੀ ਹੈ ਪਰ toString() "shifted" ਹੈ, ਤਾਂ ਇਹ ਲੋਕਲ ਟਾਈਮਜ਼ੋਨ ਦਿਖਾਵਾ ਮੁੱਦਾ ਹੈ।
• ਜੇ getTimezoneOffset() ਤਾਰੀਖ ਦੇ ਅਨੁਸਾਰ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ DST ਨੂੰ ਕ੍ਰਾਸ ਕਰ ਰਹੇ ਹੋ।

2) environment ਦੀ ਪਛਾਣ ਕਰੋ: ਟਾਈਮਜ਼ੋਨ ਅਤੇ locale

"ਮੇਰੇ ਮਸ਼ੀਨ 'ਤੇ ਹੁੰਦਾ ਹੈ" ਵਾਲੀਆਂ ਰਿਪੋਰਟਾਂ ਅਕਸਰ environment defaults ਦਿਆਂ ਅੰਤਰ ਹੁੰਦੇ ਹਨ।

• Browser: OS time zone ਸੈਟਿੰਗਾਂ ਅਤੇ browser language ਚੈੱਕ ਕਰੋ। ਫਿਰ log ਕਰੋ:

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

• Node.js / server: process time zone ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ:

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

ਜੇ ਤੁਹਾਡਾ ਸਰਵਰ UTC 'ਚ ਚੱਲਦਾ ਹੈ ਪਰ ਤੁਹਾਡਾ ਲੈਪਟਾਪ ਲੋਕਲ zone 'ਚ, ਤਾਂ formatted output ਵੱਖਰਾ ਹੋਵੇਗਾ ਜਦ ਤੱਕ ਤੁਸੀਂ explicit timeZone ਨਾ ਦਿਓ।

3) ਜਿਸ ਥਾਂ ਸਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਟੁੱਟਦਾ ਹੈ ਉਥੇ ਟੈਸਟ ਜੋੜੋ

DST boundaries ਅਤੇ edge times 'ਤੇ unit tests ਬਣਾਓ:

• DST switch ਤੋਂ ਇਕ ਘੰਟਾ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ
• ਮਹੀਨੇ/ਸਾਲ ਦੇ ਅੰਤ, ਅਤੇ 23:30 → 00:30 crossover
• ਜੇ ਤੁਹਾਡੀ ਪ੍ਰੋਡਕਟ ਕਈ ਟਾਈਮਜ਼ੋਨ ਸਹਾਰਦੀ ਹੈ ਤਾਂ ਕਈ ਟਾਈਮਜ਼ੋਨ tests

ਜੇ ਤੁਸੀਂ ਤੇਜ਼ iteration ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਟੈਸਟਿੰਗ scaffolding ਦਾ ਹਿੱਸਾ ਬਣਾਓ। ਉਦਾਹਰਣ ਲਈ, ਜਦੋਂ React + Go ਐਪ generate ਕਰ ਰਹੇ ਹੋ Koder.ai ਵਿੱਚ, ਤੁਸੀਂ ਛੋਟਾ "time contract" test suite ਸ਼ੁਰੂ ਤੋਂ ਜੋੜ ਸਕਦੇ ਹੋ (API payload examples + parsing/formatting assertions) ਤਾਂ ਜੋ regression deployment ਤੋਂ ਪਹਿਲਾਂ ਫੜੀ ਜਾ ਸਕੇ।

ਸ਼ਿੱਘਰ pre-ship ਚੈੱਕਲਿਸਟ

• Inputs ਦਾ ਸਪੱਸ਼ਟ contract: epoch milliseconds ਜਾਂ ISO 8601 with offset।
• Ambiguous strings ਜਿਵੇਂ "2025-03-02 10:00" ਨਹੀਂ ਹੋਣੇ ਚਾਹੀਦੇ।
• Formatting ਸਦਾ locale ਦੱਸ ਕਰ ਕੀਤਾ ਜਾਵੇ ਅਤੇ ਜੇ ਜ਼ਰੂਰੀ ਹੋਵੇ ਤਾਂ timeZone ਦਿਓ।
• Tests ਤੁਹਾਡੇ ਟੀਚੇ ਖੇਤਰਾਂ ਲਈ DST boundaries ਨੂੰ cover ਕਰਨ।

ਭਰੋਸੇਯੋਗ ਸਮਾਂ ਹੈਂਡਲਿੰਗ ਲਈ ਸੁਝਾਏ ਗਏ ਪੈਟਰਨ

JavaScript ਵਿੱਚ ਭਰੋਸੇਯੋਗ ਸਮਾਂ ਹੈਂਡਲਿੰਗ ਬਹੁਤ ਹੱਦ ਤੱਕ "ਸੋਰਸ ਆਫ਼ ਟਰੂਥ" ਚੁਣਨ ਅਤੇ storage ਤੋਂ display ਤੱਕ consistent ਰਹਿਣ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ।

ਇਕ ਸਧਾਰਨ best practices ਦਾ ਸੈੱਟ

UTC ਵਿੱਚ store ਅਤੇ compute ਕਰੋ। ਯੂਜ਼ਰ-ਫੇਸਿੰਗ ਲੋਕਲ ਸਮਾਂ ਨੂੰ ਕੇਵਲ ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਗਰੀ ਸਮਝੋ।

ਸਿਸਟਮਾਂ ਵਿਚਕਾਰ dates transmit ਕਰਨ ਲਈ ISO 8601 strings explicit offset ਨਾਲ ਭੇਜੋ (ਪਸੰਦਨੁਮਾ Z)। ਜੇ numeric epochs ਭੇਜਣੇ ਲਾਜ਼ਮੀ ਹਨ, ਤਾਂ ਯੂਨਿਟ ਦਾ ਦਸਤਾਵੇਜ਼ ਕਰੋ ਅਤੇ ਇੱਕ consistent convention ਰੱਖੋ (JS ਵਿੱਚ milliseconds ਆਮ default ਹੈ)।

ਮਨੁੱਖਾਂ ਲਈ ਫਾਰਮੈਟ ਕਰਨ ਲਈ Intl.DateTimeFormat (ਜਾਂ toLocaleString) ਵਰਤੋਂ, ਅਤੇ ਜਦੋਂ deterministic output ਚਾਹੀਦੇ ਹੋ ਤਾਂ explicit timeZone ਦਿਓ (ਉਦਾਹਰਨ ਲਈ, ਹਮੇਸ਼ਾਂ UTC ਜਾਂ ਕਿਸੇ ਵਿਸ਼ੇਸ਼ ਕਾਰੋਬਾਰੀ ਖੇਤਰ ਦਾ zone)।

ਫੈਸਲਾ ਗਾਈਡ: DB vs API vs UI

• Database: instant ਨੂੰ UTC ਦੇ ਰੂਪ ਵਿੱਚ ਸਟੋਰ ਕਰੋ (epoch milliseconds ਜਾਂ UTC datetime type). Local datetimes ਤੋਂ ਬਚੋ ਜਦ ਤੱਕ ਤੁਹਾਡਾ ਡੋਮੇਨ ਦਰਅਸਲ wall-clock times ਸਟੋਰ ਕਰਦਾ ਨਹੀਂ (ਜਿਵੇਂ "ਦੁਕਾਨ 09:00 ਨੂੰ ਖੁਲਦੀ ਹੈ")।
• API boundaries: Z ਵਾਲੇ ISO 8601 ਨੂੰ ਪਸੰਦ ਕਰੋ (ਉਦਾਹਰਨ: 2025-12-23T10:15:00Z)। ਜੇ epochs ਵਰਤੇ ਜਾਣ, ਤਾਂ field name ਜਿਵੇਂ createdAtMs ਰੱਖੋ ਤਾਂ ਕਿ ਯੂਨਿਟ ਸਪਸ਼ਟ ਹੋਵੇ।
• UI: ਸਟੋਰ ਕੀਤਾ UTC instant ਲੈ ਕੇ ਯੂਜ਼ਰ ਦੇ locale ਲਈ format ਕਰੋ। Scheduling UIs ਲਈ, ਟਾਈਮਜ਼ੋਨ ਨੂੰ ਸਾਫ਼ ਲੇਬਲ ਕਰੋ ਅਤੇ conversions explicit ਰੱਖੋ।

ਕਦੋਂ ਲਾਇਬ੍ਰੇਰੀ ਵਰਤਣ ਯੋਗ ਹੈ

ਜੇ ਤੁਹਾਨੂੰ recurring events, complex time zone rules, DST-safe arithmetic ("ਕੱਲ੍ਹ ਉਹੀ ਲੋਕਲ ਸਮਾਂ"), ਜਾਂ inconsistent inputs ਤੋਂ parsing ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਇੱਕ dedicated date-time library ਸੋਚੋ। ਵੈਲਯੂ clearer APIs ਅਤੇ ਘੱਟ edge-case bugs ਵਿੱਚ ਹੈ।

ਜੇ ਤੁਸੀਂ ਹੋਰ ਸਮਾਂ-ਸੰਬੰਧੀ ਮਾਰਗਦਰਸ਼ਕਾਂ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ /blog ਵੇਖੋ। ਜੇ ਤੁਸੀਂ tooling ਜਾਂ support ਵਿਕਲਪਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰ ਰਹੇ ਹੋ ਤਾਂ /pricing ਵੇਖੋ।