ਸ਼ੈਡਿਊਲਿੰਗ ਐਪਾਂ ਵਿੱਚ ਟਾਈਮ ਜ਼ੋਨ ਮੁੱਖ ਕਾਰਨ ਹਨ ਕਿ ਮੀਟਿੰਗਾਂ ਮਿਸ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਸੁਰੱਖਿਅਤ ਡੇਟਾ ਮਾਡਲ, ਆਵਰਤੀ ਨਿਯਮ, DST ਖਤਰੇ ਅਤੇ ਉਪਭੋਗਤਾ-ਮਿੱਤਰ ਕਾਪੀ ਬਾਰੇ ਜਾਨੋ।

ਟਾਈਮ ਜ਼ੋਨ ਛੋਟੀਆਂ ਗਣਿਤ ਦੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਟੁੱਟੇ ਵਾਅਦਿਆਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ। ਇੱਕ ਮੀਟਿੰਗ ਜੋ 1 ਘੰਟਾ ਹਿਲ ਜਾਏ, "ਪਰਸੋਂ ਹੀ ਠੀਕ ਸੀ" ਵਾਲੀ ਗੱਲ ਨਹੀਂ ਰਹਿੰਦੀ। ਇਹ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਕੌਣ ਆਉਂਦਾ ਹੈ, ਕੌਣ ਅਣਤਿਆਰ ਦਿਸਦਾ ਹੈ, ਅਤੇ ਕੌਣ ਕੁਝ ਮਹੱਤਵਪੂਰਨ ਚੀਜ਼ ਛੱਡ ਦਿੰਦਾ ਹੈ। ਦੋ ਵਾਰੀ ਇਹ ਹੋ ਜਾਵੇ ਤਾਂ ਲੋਕ ਕੈਲੰਡਰ 'ਤੇ ਭਰੋਸਾ ਘਟਾ ਦਿੰਦੇ ਹਨ ਅਤੇ ਹਰ ਚੀਜ਼ ਨੂੰ ਚੈਟ 'ਚ ਡਬਲ-ਚੈੱਕ ਕਰਨ ਲੱਗਦੇ ਹਨ।
ਮੂਲ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਮਨੁੱਖਾਂ ਲਈ ਸਮਾਂ ਪੱਕਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਪਰ ਸੌਫਟਵੇਅਰ ਵਿੱਚ ਇਹ ਪੱਕਾ ਨਹੀਂ। ਲੋਕ ਲੋਕਲ ਘੜੀ ਦੇ ਸਮੇਂ ("9:00 AM ਮੇਰੇ ਸਮੇਂ") ਵਿੱਚ ਸੋਚਦੇ ਹਨ। ਕੰਪਿਊਟਰ ਆਮ ਤੌਰ 'ਤੇ ਅਫਸੈਟ ("UTC+2") ਵਿੱਚ ਸੋਚਦੇ ਹਨ ਜੋ ਸਾਲ ਦੌਰਾਨ ਬਦਲ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਤੁਹਾਡੀ ਐਪ ਇਹਨਾਂ ਵਿਚਕਾਰ ਮਿਲਾਉਂਦੀ ਹੈ, ਤਾਂ ਅੱਜ ਸਹੀ ਸਮਾਂ ਦਿਖਾ ਸਕਦੀ ਹੈ ਅਤੇ ਅਗਲੇ ਮਹੀਨੇ ਗਲਤ।
ਲੱਛਣ ਵੀ ਬੇਤਰਤੀਬੀ ਵਾਂਗ ਲੱਗਦੇ ਹਨ, ਜੋ ਕਿ ਹੱਲ ਨੂੰ ਹੋਰ ਬੁਰੀ ਤਰ੍ਹਾਂ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦੇ ਹਨ। ਉਪਭੋਗਤਾ ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦੀਆਂ ਸ਼ਿਕਾਇਤਾਂ ਕਰਦੇ ਹਨ: ਮੀਟਿੰਗਾਂ "ਹਿੱਲ ਰਹੀਆਂ" ਨਜ਼ਰ ਆਉਂਦੀਆਂ ਹਨ ਜਦਕਿ ਕਿਸੇ ਨੇ ਕੁਝ ਸੋਧਿਆ ਵੀ ਨਹੀਂ, ਰਿਮਾਈਂਡਰ ਜਲਦੀ ਜਾਂ ਦੇਰ ਨਾਲ ਫਾਇਰ ਹੁੰਦੇ ਹਨ, ਸਿਰਿਜ਼ ਦੇ ਕੇਵਲ ਕੁਝ ਦਰਜੇ 1 ਘੰਟਾ ਹਿਲਦੇ ਹਨ, ਦੋ ਵੱਖਰੇ ਡਿਵਾਈਸਾਂ 'ਤੇ ਹੁਣੇ-ਹੁਣੇ ਇਕੋ ਇਨਵਾਇਟ ਵੱਖਰੇ ਸਮੇਂ ਦਿਖਾਉਂਦੀ ਹੈ, ਜਾਂ ਯਾਤਰਾ ਤੋਂ ਬਾਅਦ ਡੁਪਲਿਕੇਟ ਇਵੈਂਟ ਆ ਜਾਂਦੇ ਹਨ।
ਜਿਹੜੇ ਲੋਕ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਪ੍ਰਭਾਵਿਤ ਹੁੰਦੇ ਹਨ ਉਹ ਉਹ ਹਨ ਜੋ ਸਭ ਤੋਂ ਜ਼ਿਆਦਾ ਸ਼ੈਡਿਊਲਿੰਗ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ: ਕਈ ਦੇਸ਼ਾਂ ਵਿੱਚ ਫੈਲੇ ਰਿਮੋਟ ਟੀਮਾਂ, ਸਰਹੱਦਾਂ ਪਾਰ ਬੁੱਕ ਕਰਨ ਵਾਲੇ ਗਾਹਕ, ਅਤੇ ਯਾਤਰਾ ਕਰਨ ਵਾਲੇ। ਇਕ ਪ੍ਰੋਡਕਟ ਮੈਨੇਜਰ जो ਨੱਊਯਾਰਕ ਤੋਂ ਲੰਡਨ ਜਾ ਰਿਹਾ ਹੈ, ਉਹ ਉਮੀਦ ਕਰ ਸਕਦਾ ਹੈ ਕਿ 2:00 PM ਨੋੰਹਜ਼ਕਰਕਰੱਸ਼ կառ organizer's time zone ਉਤੇ ਟਿਕਿਆ ਰਹੇਗਾ, ਜਦਕਿ ਯਾਤਰੀ ਉਮੀਦ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਉਸਦੀ ਮੌਜੂਦਾ ਲੋਕਲ ਟਾਈਮ ਦੇ ਅਨੁਸਾਰ ਅਨੁਕੂਲ ਹੋਵੇਗਾ। ਦੋਹਾਂ ਉਮੀਦਾਂ ਵਾਜਬ ਹਨ। ਸਿਰਫ ਇਕ ਹੀ ਸਚ ਹੋ ਸਕਦੀ ਹੈ, ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਸਾਫ ਨਿਯਮ ਠਹਿਰਾਉਣੇ ਪੈਣਗੇ।
ਇਹ ਸਿਰਫ਼ ਇਵੈਂਟ ਕਾਰਡ 'ਤੇ ਦਿਖਾਈ ਦੇਣ ਵਾਲੇ ਸਮੇਂ ਬਾਰੇ ਨਹੀਂ ਹੈ। ਟਾਈਮ ਜ਼ੋਨ ਨਿਯਮ ਸਿੰਗਲ ਇਵੈਂਟ, ਆਵਰਤੀ ਇਵੈਂਟ, ਰਿਮਾਈਂਡਰ, ਇਨਵਾਈਟ ਈਮੇਲ ਅਤੇ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ ਜੋ ਕਿਸੇ ਨਿਸ਼ਚਿਤ ਪਲ 'ਤੇ ਟ੍ਰਿਗਰ ਹੁੰਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਹਰ ਇੱਕ ਚੀਜ਼ ਲਈ ਨਿਯਮ ਪਰਿਭਾਸ਼ਿਤ ਨਹੀਂ ਕਰਦੇ, ਤਾਂ ਤੁਹਾਡਾ ਡੇਟਾ ਮਾਡਲ ਅਚਾਨਕ ਉਹ ਨਿਯਮ ਪਰਿਭਾਸ਼ਿਤ ਕਰ ਦੇਵੇਗਾ, ਅਤੇ ਉਪਭੋਗਤਾ ਇਹ ਗਲਤੀ ਮਹਿੰਗੀ ਤਰ੍ਹਾਂ ਪਤਾ ਲਗਾਓਗੇ।
ਇਕ ਸਧਾਰਣ ਉਦਾਹਰਨ: ਇੱਕ ਸਾਪਤਾਹਿਕ "ਸੋਮਵਾਰ 9:00 AM" ਸਟੈਂਡਅੱਪ ਮਾਰਚ ਵਿੱਚ ਬਣਾਇਆ ਗਿਆ। ਅਪ੍ਰੈਲ ਵਿੱਚ, ਇੱਕ ਹाज़ਿਰ ਰਹਿਣ ਵਾਲੇ ਖੇਤਰ ਲਈ DST ਬਦਲਦਾ ਹੈ। ਜੇ ਤੁਹਾਡੀ ਐਪ ਨੇ ਇਸਨੂੰ "ਹਰ 7 ਦਿਨ ਇੱਕੋ UTC ਪਲ 'ਤੇ" ਸਟੋਰ ਕੀਤਾ, ਤਾਂ ਉਸ ਹाज़ਿਰ ਹੀ ਲਈ ਇਹ ਅਚਾਨਕ 10:00 AM ਦਿਖੇਗਾ। ਜੇ ਤੁਹਾਡੀ ਐਪ ਨੇ ਇਸਨੂੰ "ਆਯੋਜਕ ਦੇ ਟਾਈਮ ਜ਼ੋਨ ਵਿੱਚ ਹਰ ਸੋਮਵਾਰ 9:00 AM" ਵਜੋਂ ਸਟੋਰ ਕੀਤਾ, ਤਾਂ ਇਹ 9:00 AM ਤੇ ਹੀ ਰਹਿੰਦਾ ਹੈ ਅਤੇ UTC ਪਲ ਬਦਲਦਾ ਹੈ। ਦੋਹਾਂ ਚੋਣਾਂ ਕੰਮ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਐਪ ਨੂੰ ਲਗਾਤਾਰ ਅਤੇ ਸਚਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਜਿਆਦਾਤਰ ਟਾਈਮ ਜ਼ੋਨ ਬੱਗ ਕੁੱਝ ਮੂਲ ਧਾਰਨਾਵਾਂ ਨੂੰ ਮਿਲਾਉਣ ਤੋਂ ਹੁੰਦੇ ਹਨ। ਸਹੀ ਸ਼ਬਦ ਵਰਤਣਾ ਤੁਹਾਡੀ UI ਕਾਪੀ ਨੂੰ ਵੀ واضح ਬਣਾਉਂਦਾ ਹੈ।
UTC (Coordinated Universal Time) ਗਲੋਬਲ ਰੈਫ਼ਰੈਂਸ ਘੜੀ ਹੈ। ਇਸਨੂੰ ਇੱਕ ਇਕੋ ਟਾਈਮਲਾਈਨ ਸਮਝੋ ਜੋ ਸਾਰਿਆਂ ਨੇ ਸ਼ੇਅਰ ਕੀਤਾ ਹੁੰਦਾ ਹੈ।
"ਆਬਸਲੂਟ ਸਮਾਂ" ਇੱਕ ਨਿਸ਼ਚਿਤ ਪਲ ਹੁੰਦਾ ਹੈ ਉਸ ਟਾਈਮਲਾਈਨ 'ਤੇ, ਜਿਵੇਂ 2026-01-16 15:00:00 UTC। ਜੇ ਦੋ ਲੋਕ ਵੱਖ-ਵੱਖ ਦੇਸ਼ਾਂ ਵਿੱਚ ਉਸ ਪਲ ਨੂੰ ਵੇਖਦੇ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਉਹੀ ਘਟਨਾ ਦੇਖਣੀ ਚਾਹੀਦੀ ਹੈ, ਸਿਰਫ਼ ਆਪਣੀਆਂ ਲੋਕਲ ਘੜੀਆਂ ਨਾਲ ਵੱਖ-ਵੱਖ ਦਿਖਾਈ ਦੇਵੇਗੀ।
ਲੋਕਲ ਸਮਾਂ ਉਹ ਹੈ ਜੋ ਮਨੁੱਖ ਆਪਣੀ ਘੜੀ 'ਤੇ ਵੇਖਦਾ ਹੈ, ਜਿਵੇਂ "9:00 AM"। ਇਹ ਆਪਣੇ ਆਪ ਵਿੱਚ ਕਿਸੇ ਪਲ ਦੀ ਪਛਾਣ ਲਈ ਕਾਫ਼ੀ ਨਹੀਂ। ਤੁਹਾਨੂੰ ਇੱਕ ਥਾਂ ਨਿਯਮ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
ਅਫਸੈਟ UTC ਤੋਂ ਕਿਸੇ ਪਲ 'ਤੇ ਦੇ ਫਰਕ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਜਿਵੇਂ UTC+2 ਜਾਂ UTC-5। ਅਫਸੈਟ ਸਾਲ ਭਰ ਬਦਲ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਸਿਰਫ਼ "UTC+2" ਸਟੋਰ ਕਰਨਾ ਖ਼ਤਰਨਾਕ ਹੈ।
ਟਾਈਮ ਜ਼ੋਨ ID ਅਸਲ ਨਿਯਮ ਸੈਟ ਹੁੰਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ IANA ਨਾਂ ਵਾਲਾ, ਜਿਵੇਂ America/New_York ਜਾਂ Europe/Berlin। ID ਉਸ ਜ਼ੋਨ ਦੀਆਂ ਇਤਿਹਾਸਕ ਅਤੇ ਭਵਿੱਖੀ ਬਦਲਾਵਾਂ, ਸਮੇਤ DST ਨੂੰ ਕੈਪਚਰ ਕਰਦਾ ਹੈ।
ਵਿਆਖਿਆਤਮਕ ਫ਼ਰਕ:
DST ਉਹ ਹੈ ਜਦੋਂ ਕਿਸੇ ਖੇਤਰ ਦੀਆਂ ਘੜੀਆਂ ਅੱਗੇ ਜਾਂ ਪਿੱਛੇ ਵੱਖ-ਵੱਖ ਸਮੇਤ ਇੱਕ ਘੰਟਾ ਘੁੰਮਦੀਆਂ ਹਨ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ UTC ਅਫਸੈਟ ਬਦਲ ਜਾਂਦਾ ਹੈ。
DST ਦੇ ਦੋ ਹੈਰਾਨ ਕਰਨ ਵਾਲੇ ਪਲ:
ਵਾਲ-ਕਲੌਕ ਸਮਾਂ ਉਹ ਹੈ ਜੋ ਉਪਭੋਗਤਾ ਟਾਈਪ ਕਰਦੇ ਹਨ: "ਹਰ ਸੋਮਵਾਰ 9:00 AM"। ਆਬਸਲੂਟ ਸਮਾਂ ਉਹ ਹੈ ਜੋ ਤੁਹਾਡੀ ਸਿਸਟਮ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨਾ ਪੈਦਾ ਹੈ: "ਇਸ ਨਿਸ਼ਚਿਤ UTC ਪਲ 'ਤੇ ਰਿਮਾਈਂਡਰ ਭੇਜੋ"। ਆਵਰਤੀ ਇਵੈਂਟ ਅਕਸਰ ਵਾਲ-ਕਲੌਕ ਨਿਯਮ ਵਜੋਂ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ, ਫਿਰ ਇੱਕ ਸਿਰੀਜ਼ ਆਬਸਲੂਟ ਸਮਿਆਂ ਵਿੱਚ ਬਦਲ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ।
ਉਪਭੋਗਤਾ ਸੋਚਦੇ ਹਨ ਉਹਨਾਂ ਨੇ "9:00 AM ਆਪਣੇ ਟਾਈਮ ਜੋਨ ਵਿੱਚ ਬੁੱਕ ਕੀਤਾ"। ਤੁਹਾਡਾ ਡੇਟਾਬੇਸ ਸਾਇਦ 2026-03-10 13:00 UTC ਸਟੋਰ ਕਰਦਾ ਹੋਵੇ। ਦੋਹਾਂ ਸਹੀ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਸਿਰਫ਼ ਜੇ ਤੁਸੀਂ ਇਹ ਵੀ ਯਾਦ ਰੱਖੋ ਕਿ ਨੇੜੇ ਨਿਯਮ ਕੀ ਸਨ।
ਡਿਵਾਈਸ ਵੀ ਟਾਈਮ ਜ਼ੋਨ ਬਦਲ ਸਕਦੇ ਹਨ। ਲੋਕ ਯਾਤਰਾ ਕਰਦੇ ਹਨ, ਅਤੇ ਲੈਪਟੌਪ ਆਟੋ-ਸਵਿੱਚ ਕਰ ਸਕਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੀ ਐਪ ਚੁਪਚਾਪ ਸਟੋਰ ਕੀਤਾ ਗਿਆ "9:00 AM" ਨੂੰ ਡਿਵਾਈਸ ਦੇ ਨਵੇਂ ਜ਼ੋਨ ਨਾਲ ਦੁਬਾਰਾ ਵਿਆਖਿਆ ਕਰਦੀ ਹੈ, ਤਾਂ ਉਪਭੋਗਤਾ ਮਹਿਸੂਸ ਕਰਨਗੇ ਕਿ ਮੀਟਿੰਗ ਦਾ ਸਮਾਂ "ਹਿੱਲ ਗਿਆ" ਜਦੋਂ ਕਿ ਉਹਨਾਂ ਨੇ ਕੁਝ ਵੀ ਨਹੀਂ ਕੀਤਾ।
ਜਿਆਦਾਤਰ "ਮੇਰੀ ਮੀਟਿੰਗ ਹਿੱਲ ਗਈ" ਬੱਗ ਡੇਟਾ ਮਾਡਲ ਬੱਗ ਹੁੰਦੇ ਹਨ। ਇਕ-ਵਾਰੀ ਦੀਆਂ ਘਟਨਾਵਾਂ ਲਈ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਡੀਫੌਲਟ ਇਹ ਹੈ: ਇਕੋ UTC ਪਲ ਸਟੋਰ ਕਰੋ, ਅਤੇ ਦਿਖਾਉਣ ਵੇਲੇ ਹੀ ਯੂਜ਼ਰ ਦੇ ਲੋਕਲ ਸਮੇਂ ਵਿੱਚ ਡਾਲਾ ਕਰੋ।
ਇੱਕ-ਵਾਰੀ ਦੀ ਘਟਨਾ ਜਿਵੇਂ "Oct 12, 2026 at 15:00 in Berlin." ਉਹ ਪਲ ਇਕ ਵਾਰੀ ਹੁੰਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ UTC (ਟਾਈਮਲਾਈਨ 'ਤੇ ਇੱਕ ਪਲ) ਵਜੋਂ ਸਟੋਰ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਹਮੇਸ਼ਾ ਇੱਕੋ ਹੀ ਪਲ 'ਤੇ ਨਕਸ਼ਾਤ ਹੋਵੇਗਾ, ਭਾਵੇਂ ਦਰੇਖਤਕਾਰੀ ਵੇਖਣ ਵਾਲਾ ਕਿੱਥੇ ਵੀ ਹੋਵੇ।
ਸਿਰਫ਼ ਇੱਕ ਲੋਕਲ ਸਮਾਂ (ਜਿਵੇਂ "15:00") ਸਟੋਰ ਕਰਨ ਨਾਲ ਤਿੱਖੀ ਸਮੱਸਿਆ ਆਉਂਦੀ ਹੈ ਜਦ ਕੋਈ ਹੋਰ ਟਾਈਮ ਜ਼ੋਨ ਤੋਂ ਵੇਖਦਾ ਹੈ ਜਾਂ ਬਣਾਉਣ ਵਾਲੇ ਨੇ ਆਪਣੇ ਡਿਵਾਈਸ ਸੈਟਿੰਗ ਬਦਲੀ। ਸਿਰਫ਼ ਅਫਸੈਟ (ਜਿਵੇਂ "+02:00") ਸਟੋਰ ਕਰਨ ਨਾਲ DST ਕਾਰਨ ਬਾਅਦ ਤੋਟੇ ਹੋ ਜਾਂਦਾ ਹੈ। "+02:00" ਕੋਈ ਥਾਂ ਨਹੀਂ, ਇਹ ਸਿਰਫ਼ ਅਸਥਾਈ ਨਿਯਮ ਹੈ।
ਕਦੋਂ ਤੁਹਾਨੂੰ UTC ਨਾਲ਼ ਇਕ ਟਾਈਮ ਜ਼ੋਨ ID ਵੀ ਸਟੋਰ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ? ਜਦ ਵੀ ਤੁਸੀਂ ਕੇਵਲ ਸਟੋਰ ਕੀਤੇ ਗਏ ਪਲ ਦੀਆਂ ਪਾਬੰਦੀਆਂ ਨਹੀਂ, ਬਲਕਿ ਬਣਾਉਣ ਵਾਲੇ ਨੇ ਕੀ ਮਨਾਇਆ ਸੀ ਉਹ ਜਾਣਣਾ ਚਾਹੁੰਦੇ ਹੋ। Europe/Berlin ਵਰਗਾ zone ID ਡਿਸਪਲੇ, ਆਡਿਟ ਅਤੇ ਸਹਾਇਤਾ ਲਈ ਲਾਭਦਾਇਕ ਹੈ, ਅਤੇ ਆਵਰਤੀ ਇਵੈਂਟਸ ਲਈ ਜਰੂਰੀ ਬਣ ਜਾਂਦਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਆਖ ਸਕਦਾ ਹੈ: "ਇਹ ਇਵੈਂਟ 15:00 Berlin ਸਮੇਂ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ," ਭਾਵੇਂ ਬਾਅਦ ਵਿੱਚ Berlin ਦਾ ਅਫਸੈਟ ਬਦਲ ਜਾਵੇ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਰਿਕਾਰਡ ਇੱਕ ਇੱਕ-ਵਾਰੀ ਇਵੈਂਟ ਲਈ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ:
start_at_utc (ਅਤੇ end_at_utc)created_at_utccreator_time_zone_id (IANA ਨਾਂ)original_input (ਉਸ ਟੈਕਸਟ ਜਾਂ ਫ਼ੀਲਡਾਂ ਜੋ ਉਪਭੋਗਤਾ ਨੇ ਟਾਈਪ ਕੀਤੇ)input_offset_minutes (ਵਿਕਲਪੀ, ਡੀਬੱਗਿੰਗ ਲਈ)ਸਹਾਇਤਾ ਲਈ, ਇਹ ਫੀਲਡਾਂ ਇੱਕ ਅਸਪਸ਼ਟ ਸ਼ਿਕਾਇਤ ਨੂੰ ਸਾਫ ਰੀਪਲੇ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ: ਉਪਭੋਗਤਾ ਨੇ ਕੀ ਟਾਈਪ ਕੀਤਾ, ਉਨ੍ਹਾਂ ਦੇ ਡਿਵਾਈਸ ਨੇ ਕਿਹੜਾ ਜ਼ੋਨ ਦਾਅਵਾ ਕੀਤਾ, ਅਤੇ ਤੁਹਾਡੀ ਸਿਸਟਮ ਨੇ ਕੀ ਪਲ ਸਟੋਰ ਕੀਤਾ।
ਕਥਾਨਕ ਜਗ੍ਹਾ 'ਤੇ ਕਿੱਥੇ ਕਨਵਰਜਨ ਹੋਣੀ ਹੈ ਇਸ 'ਤੇ ਸਖ਼ਤ ਰਹੋ। ਸਰਵਰ ਨੂੰ ਸਟੋਰੇਜ਼ ਲਈ ਸਚਾਈ ਦਾ ਸਰੋਤ ਮਨੋ (ਕੇਵਲ UTC), ਅਤੇ ਕਲੀਐਂਟ ਨੂੰ ਇਰਾਦੇ ਦਾ ਸਰੋਤ (ਲੋਕਲ ਸਮਾਂ ਨਾਲ ਇਕ ਟਾਈਮ ਜ਼ੋਨ ID) ਮੰਨੋ। ਲੋਕਲ ਸਮੇਂ ਨੂੰ UTC ਵਿੱਚ ਇੱਕ ਵਾਰੀ ਬਦਲੋ, ਬਣਾਉਣ ਜਾਂ ਐਡੀਟ ਸਮੇਂ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ UTC ਨੂੰ ਦੁਬਾਰਾ "ਰੀ-ਕਨਵਰਟ" ਨਾ ਕਰੋ। ਚੁਪਚਾਪ ਬਦਲ ਅਕਸਰ ਹੋਂਦ ਵਿੱਚ ਆਉਂਦਾ ਹੈ ਜਦ ਦੋਹਾਂ ਪਾਸੇ ਬਦਲੀ ਕਰ ਰਹੇ ਹੁੰ ਜਾਂ ਜਦ ਇੱਕ ਪਾਸਾ ਦਿਆਂਟਮੰਤ ਕਰਦਾ ਹੈ ਬਜਾਏ ਉਪਭੋਗਤਾ ਵਲੋਂ ਦਿੱਤੇ ਜ਼ੋਨ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ।
ਜੇ ਤੁਸੀਂ ਕਈ ਕਲਾਈਂਟਾਂ ਤੋਂ ਘਟਨਾਵਾਂ ਸਵੀਕਾਰਦੇ ਹੋ, ਤਾਂ ਟਾਈਮ ਜ਼ੋਨ ID ਨੂੰ ਲੌਗ ਕਰੋ ਅਤੇ ਇਸਦੀ ਜਾਂਚ ਕਰੋ। ਜੇ ਇਹ ਗੈਰ-ਹਾਜ਼ਰ ਹੈ, ਤਾਂ ਗੈਸ ਕਰਣ ਦੀ ਥਾਂ ਉਪਭੋਗਤਾ ਨੂੰ ਚੋਣ ਕਰਨ ਲਈ ਪੁੱਛੋ। ਇਹ ਛੋਟੀ ਪ੍ਰੈੰਪ ਬਾਅਦ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਗੁੱਸੇ ਵਾਲੀਆਂ ਟਿਕਟਾਂ ਰੋਕਦੀ ਹੈ।
ਜਦ ਉਪਭੋਗਤਾ ਵਾਰ-ਵਾਰ ਸਮਾਂ "ਹਿੱਲਦਾ" ਵੇਖਦੇ ਹਨ, ਤਾਂ ਅਕਸਰ ਇਸਦਾ ਕਾਰਨ ਸਿਸਟਮ ਦੇ ਵੱਖ-ਵੱਖ ਹਿੱਸਿਆਂ ਦਾ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਨਾਲ ਤਬਦੀਲ ਕਰਨਾ ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਥਾਂ ਚੁਣੋ ਜਿੱਥੇ ਕਨਵਰਜਨ ਦਾ ਸੱਚਾਈ ਸਰੋਤ ਹੋਵੇ। ਬਹੁਤ ਟੀਮਾਂ ਸਰਵਰ ਨੂੰ ਚੁਣਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਇਹ ਵੈੱਬ, ਮੋਬਾਈਲ, ਈਮੇਲ ਅਤੇ ਬੈਕਗ੍ਰਾਊਂਡ ਜੌਬਾਂ ਲਈ ਇੱਕੋ ਨਤੀਜਾ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ। ਕਲਾਈਂਟ ਅਜੇ ਵੀ ਪ੍ਰੀਵਿਊ ਦੇ ਸਕਦਾ ਹੈ, ਪਰ ਸਰਵਰ ਅੰਤਿਮ ਸਟੋਰ ਕੀਤੇ ਮੁੱਲ ਦੀ ਪੁਸ਼ਟੀ ਕਰੇ।
ਇਕ ਦੁਹਰਾਈ ਯੋਗ ਪਾਈਪਲਾਈਨ ਬਹੁਤ ਸੀਰਪ੍ਰਾਈਜ਼ਾਂ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ:
2026-03-10 09:00) ਅਤੇ ਇਵੈਂਟ ਟਾਈਮ ਜ਼ੋਨ ਨੂੰ IANA ਨਾਂ ਵਜੋਂ (America/New_York) ਲਵੋ, ਨਾ ਕਿ "EST" ਵਰਗੀਆਂ ਕਟਿੰਗ-ਛੋਟੀਆਂ।ਉਦਾਹਰਨ: ਨਿਊਯਾਰਕ ਵਿੱਚ ਹੋਸਟ "Tue 9:00 AM (America/New_York)" ਬਣਾਉਂਦਾ ਹੈ। ਟੀਮਮੇਟ ਬਰਲਿਨ ਵਿੱਚ ਇਸਨੂੰ "3:00 PM (Europe/Berlin)" ਵਜੋਂ ਵੇਖੇਗਾ ਕਿਉਂਕਿ ਉਹੀ UTC ਇੰਸਟੈਂਟ ਉਨ੍ਹਾਂ ਦੇ ਜ਼ੋਨ ਵਿੱਚ ਦਿਖਾਇਆ ਗਿਆ।
ਸਾਰੀ-ਦੇ-ਦਿਨ ਇਹ ਨਹੀਂ ਹੁੰਦਾ ਕਿ "00:00 UTC to 00:00 UTC"। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਕਿਸੇ ਖਾਸ ਟਾਈਮ ਜ਼ੋਨ ਵਿੱਚ ਇੱਕ ਤਾਰੀਖ ਰੇਂਜ ਹੁੰਦਾ ਹੈ। ਸਾਰੀ-ਦੇ-ਦਿਨ ਨੂੰ date-only ਮੁੱਲਾਂ (start_date, end_date) ਅਤੇ ਉਸ ਜ਼ੋਨ ਨਾਲ ਸਟੋਰ ਕਰੋ ਜਿਸ ਨਾਲ ਉਸ ਤਾਰੀਖ ਨੂੰ ਵਿਆਖਿਆ ਕੀਤਾ ਗਿਆ ਸੀ। ਨਹੀਂ ਤਾਂ, ਇੱਕ ਸਾਰੀ-ਦੇ-ਦਿਨ ਇਵੈਂਟ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ UTC ਦੇ ਨੈਗੇਟਿਵ ਅਫਸੈਟ ਵਾਲੇ ਖੇਤਰ ਵਿੱਚ ਪਿਛਲੇ ਦਿਨ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਨਜ਼ਰ ਆ ਸਕਦਾ ਹੈ।
ਸ਼ਿਪਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਅਸਲੀ ਜ਼ਿੰਦਗੀ ਦੇ ਕੇਸ ਟੈਸਟ ਕਰੋ: ਇਕ ਇਵੈਂਟ ਬਣਾਓ, ਡਿਵਾਈਸ ਟਾਈਮ ਜ਼ੋਨ ਬਦਲੋ, ਫਿਰ ਦੁਬਾਰਾ ਖੋਲ੍ਹੋ। ਟਾਈਮਡ ਇਵੈਂਟਸ ਲਈ ਉਹੀ ਪਲ ਅਤੇ ਸਾਰੀ-ਦੇ-ਦਿਨ ਲਈ ਉਹੀ ਲੋਕਲ ਤਾਰੀਖ ਹੀ ਰਹਿਣੀ ਚਾਹੀਦੀ ਹੈ, ਨਾ ਕਿ ਚੁਪਚਾਪ ਬਦਲੇ।
ਜ਼ਿਆਦਾਤਰ ਸ਼ੈਡਿਊਲਿੰਗ ਦੀਆਂ ਗਲਤੀਆਂ ਉਸ ਵੇਲੇ ਆਉਂਦੀਆਂ ਹਨ ਜਦੋਂ ਇਕ ਇਵੈਂਟ ਦੁਹਰਾਇਆ ਜਾਂਦਾ ਹੈ। ਆਮ ਗਲਤੀ ਹੈ ਰਿੱਕਰੈਂਸ ਨੂੰ "ਸਿਰਫ਼ ਦੀਨ ਦੀ ਤਾਰੀਖ ਨੂੰ ਆਗੇ ਕੋਪੀਆਂ" ਸਮਝਨਾ। ਪਹਿਲਾਂ ਇਹ ਨਿਰਧਾਰਤ ਕਰੋ ਕਿ ਇਵੈਂਟ ਕਿਸ 'ਤੇ ਲੱਗਦਾ ਹੈ:
ਅਕਸਰ ਕੈਲੰਡਰਾਂ (ਮੀਟਿੰਗਾਂ, ਰਿਮਾਈਂਡਰ, ਦਫ਼ਤਰ ਦੇ ਘੰਟੇ) ਲਈ ਉਪਭੋਗਤਾ ਵਾਲ-ਟਾਈਮ ਦੀ ਉਮੀਦ ਰੱਖਦੇ ਹਨ। "ਹਰ ਸੋਮਵਾਰ 9:00 AM" ਆਮ ਤੌਰ 'ਤੇ ਮਤਲਬ 9:00 AM ਚੁਣੀ ਹੋਈ ਸ਼ਹਿਰ ਦੀ ਲੋਕਲ ਘੜੀ ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਨਾ ਕਿ "ਹਮੇਸ਼ਾਂ ਇੱਕੋ UTC ਪਲ"।
ਰਿਕਰੈਂਸ ਨੂੰ ਇੱਕ ਨਿਯਮ ਵਜੋਂ ਸਟੋਰ ਕਰੋ ਅਤੇ ਉਸਨੂੰ ਵਿਆਖਿਆ ਕਰਨ ਲਈ ਜਰੂਰੀ ਸੰਦਰਭ ਰੱਖੋ, ਨਾ ਕਿ ਪਹਿਲਾਂ ਹੀ timestamps ਦੀ ਲਿਸਟ ਬਣਾਓ:
ਇਹ ਤੁਹਾਨੂੰ DST ਦੇ ਬਿਨਾਂ "ਚੁਪਚਾਪ ਸ਼ਿਫਟ" ਸੰਭਾਲਣ ਅਤੇ ਸੋਧਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਬਣਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ।
ਜਦੋਂ ਤੁਹਾਨੂੰ ਕਿਸੇ ਤਾਰੀਖ ਰੇਂਜ ਲਈ ਘਟਨਾਵਾਂ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਇਵੈਂਟ ਦੇ ਜ਼ੋਨ ਵਿੱਚ ਲੋਕਲ ਟਾਈਮ ਵਿੱਚ ਜਨਰੇਟ ਕਰੋ, ਫਿਰ ਹਰ ਘਟਨਾ ਨੂੰ UTC ਵਿੱਚ ਬਦਲੋ। ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਲੋਕਲ ਸ਼ਬਦਾਂ ਵਿੱਚ "ਅਗਲਾ ਹਫ਼ਤਾ" ਜਾਂ "ਅਗਲਾ ਸੋਮਵਾਰ" ਜੋੜੋ, ਨਾ ਕਿ UTC ਵਿੱਚ "+ 7 * 24 ਘੰਟੇ"।
ਸਧਾ ਮਨ ਸੌਚ: ਜੇ ਉਪਭੋਗਤਾ ਨੇ ਬਰਲਿਨ ਵਿੱਚ 9:00 AM ਹਫ਼ਤਾਵਾਰ ਚੁਣਿਆ, ਤਾਂ ਹਰ ਪੈਦਾ ਕੀਤੀ ਘਟਨਾ ਬਰਲਿਨ ਸਮੇਂ 9:00 AM ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਜਦ ਬਰਲਿਨ DST ਬਦਲਦਾ ਹੈ ਤਾਂ UTC ਮੂਲ ਬਦਲੇਗਾ, ਅਤੇ ਇਹ ਠੀਕ ਹੈ।
ਜਦ ਉਪਭੋਗਤਾ ਯਾਤਰਾ ਕਰਦੇ ਹਨ, ਤਾਂ ਵਿਵਹਾਰ ਬਾਰੇ ਸਪੱਸ਼ਟ ਹੋਵੋ। ਬਰਲਿਨ-ਅੰਕਿਤ ਇਵੈਂਟ ਹੇਠਾਂ ਵੀ 9:00 AM ਬਰਲਿਨ ਸਮੇਂ ਤੇ ਹੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਤੇ ਨਿਊਯਾਰਕ ਦਾ ਯਾਤਰੀ ਇਸਨੂੰ ਆਪਣੇ ਲੋਕਲ ਤਬਦੀਲੀ ਦੇ ਤੌਰ 'ਤੇ ਵੇਖੇਗਾ। ਜੇ ਤੁਸੀਂ "ਫਲੋਟਿੰਗ" ਇਵੈਂਟਸ ਸਹਾਇਤਾ ਕਰਦੇ ਹੋ ਜੋ ਦਰਸ਼ਕ ਦੇ ਮੌਜੂਦਾ ਟਾਈਮ ਜ਼ੋਨ ਨੂੰ ਫਾਲੋ ਕਰਦੇ ਹਨ, ਤਾਂ ਇਸਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਲੇਬਲ ਕਰੋ। ਇਹ ਉਪਯੋਗੀ ਹੈ, ਪਰ ਜਦ ਇਹ ਬੇਖਬਰ ਹੋਵੇ ਤਾਂ ਲੋਕ ਹੈਰਾਨ ਹੁੰਦੇ ਹਨ।
DST ਸਮੱਸਿਆਵਾਂ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਯਾਦਗਾਰ ਨਹੀਂ ਹੁੰਦੀਆਂ ਕਿਉਂਕਿ ਐਪ ਉਹ ਇੱਕ ਸਮਾਂ ਦਿਖਾਉਂਦੀ ਹੈ ਜਦ ਉਹ ਬੁੱਕ ਕਰਦੇ ਹਨ, ਫਿਰ ਬਾਅਦ ਵਿੱਚ ਇੱਕ ਵੱਖਰਾ ਸਮਾਂ ਦਿਖਾਉਂਦੀ ਹੈ। ਠੀਕ ਕਰਨ ਲਈ صرف ਤਕਨੀਕੀ ਹੱਲ ਨਹੀਂ ਕਾਫ਼ੀ। ਤੁਹਾਨੂੰ ਸਪਸ਼ਟ ਨਿਯਮ ਅਤੇ ਸਪਸ਼ਟ ਸ਼ਬਦਾਂ ਦੀ ਲੋੜ ਹੈ।
ਜਦ ਘੜੀਆਂ ਅੱਗੇ ਵਧਦੀਆਂ ਹਨ, ਕੁਝ ਲੋਕਲ ਸਮੇਂ ਮੌਜੂਦ ਨਹੀਂ ਰਹਿੰਦੇ। ਇੱਕ ਕਲਾਸਿਕ ਉਦਾਹਰਨ 02:30 DST ਸ਼ੁਰੂ ਦਿਨ 'ਤੇ। ਜੇ ਤੁਸੀਂ ਕਿਸੇ ਨੂੰ ਇਹ ਚੁਣਨ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨਾ ਪਵੇਗਾ ਕਿ ਇਹਦਾ ਕੀ ਮਤਲਬ ਹੈ।
ਜਦ ਘੜੀਆਂ ਪਿੱਛੇ ਆਉਂਦੀਆਂ ਹਨ, ਉਲਟ ਹੁੰਦਾ ਹੈ: ਉਹੀ ਲੋਕਲ ਸਮਾਂ ਦੁਬਾਰਾ ਹੁੰਦਾ ਹੈ। "01:30" ਦੋ ਵਾਰੀ ਹੋ ਸਕਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਨਹੀਂ ਪੁੱਛਦੇ, ਤਾਂ ਤੁਸੀਂ ਅੰਦਾਜ਼ਾ ਲਗਾਉ ਰਹੇ ਹੋ, ਅਤੇ ਲੋਕ ਨੋਟਿਸ ਕਰਦੇ ਹਨ ਜਦ ਉਹ ਇੱਕ ਘੰਟਾ ਪਹਿਲਾਂ ਜਾਂ ਦੇਰ ਨਾਲ ਜੁੜਦੇ ਹਨ।
ਅਮਲੀ ਨਿਯਮ ਜੋ ਹੈਰਾਨੀ ਰੋਕਦੇ ਹਨ:
ਇੱਕ ਹਕੀਕਤੀ ਸਹਾਇਤਾ ਟਿਕਟ ਸ਼ੁਰੂ ਕਰਨ ਵਾਲੀ ਲਾਇਨ: ਕਿਸੇ ਨੇ ਅਗਲੇ ਮਹੀਨੇ ਲਈ ਨਿਊਯਾਰਕ ਵਿੱਚ "02:30" ਬੁੱਕ ਕੀਤਾ, ਫਿਰ ਆਉਣ ਵਾਲੇ ਦਿਨ ਤੇ ਐਪ ਚੁਪਚਾਪ "03:30" ਦਿਖਾਉਂਦੀ ਹੈ। ਬਣਾਉਣ ਸਮੇਂ ਬਹਤਰ ਕਾਪੀ ਸਧਾਰਨ ਹੈ: "Mar 10 ਨੂੰ ਘੜੀ ਬਦਲ ਕਾਰਨ ਇਹ ਸਮਾਂ ਮੌਜੂਦ ਨਹੀਂ ਹੈ। 01:30 ਜਾਂ 03:00 ਚੁਣੋ।" ਜੇ ਤੁਸੀਂ ਆਟੋ-ਅਡਜਸਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਕਹੋ: "ਅਸੀਂ ਇਸਨੂੰ 03:00 'ਤੇ ਲਿਆ ਗਿਆ ਕਿਉਂਕਿ 02:30 ਉਸ ਦਿਨ ਸਕਿਪ ਹੁੰਦਾ ਹੈ।"
ਜੇ ਤੁਸੀਂ DST ਨੂੰ UI ਏਜ ਕੇਸ ਵਜੋਂ ਟਰੀਟ ਕਰੋਗੇ ਤਾਂ ਇਹ ਭਰੋਸੇ ਦੀ ਸਮੱਸਿਆ ਵਜੋਂ ਸਾਹਮਣਾ ਆਏਗੀ। ਜੇ ਤੁਸੀਂ ਇਸਨੂੰ ਇਕ ਪ੍ਰੋਡਕਟ ਨਿਯਮ ਵਜੋਂ ਲਵੋਗੇ ਤਾਂ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਭਰੋਸੇਯੋਗ ਬਣ ਜਾਂਦਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਗੁੱਸੇਦਾਰ ਟਿਕਟ ਕੁਝ ਹੀ ਮੁੜ-ਆਉਣ ਵਾਲੀਆਂ ਗਲਤੀਆਂ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ। ਐਪ ਸਮਾਂ "ਬਦਲ ਜਾਂਦਾ" ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ, ਪਰ ਅਸਲ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਨਿਯਮ ਡੇਟਾ, ਕੋਡ, ਅਤੇ ਕਾਪੀ ਵਿੱਚ ਸਪਸ਼ਟ ਨਹੀਂ ਸਨ।
ਆਮ ਨਾਕਾਮੀ ਸਿਰਫ਼ ਅਫਸੈਟ (ਜਿਵੇਂ -05:00) ਸਟੋਰ ਕਰਨਾ ਹੈ ਬਜਾਏ ਇੱਕ ਅਸਲ IANA ਟਾਈਮ ਜ਼ੋਨ (America/New_York) ਦੇ। ਅਫਸੈਟ DST ਸ਼ੁਰੂ ਜਾਂ ਖਤਮ ਹੋਣ 'ਤੇ ਬਦਲ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਇੱਕ ਇਵੈਂਟ ਜੋ ਮਾਰਚ ਵਿੱਚ ਸਹੀ ਸੀ, ਨਵੰਬਰ ਵਿੱਚ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ।
ਟਾਈম ਜ਼ੋਨ ਸ਼ਾਰਟਫਾਰਮ ਵੀ ਇੱਕ ਆਮ ਬੱਗ ਸਥਾਨ ਹਨ। "EST" ਵੱਖ-ਵੱਖ ਲੋਕਾਂ ਅਤੇ ਸਿਸਟਮਾਂ ਲਈ ਵੱਖ-ਵੱਖ ਮਤਲਬ ਰੱਖ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੁਝ ਪਲੇਟਫਾਰਮ ਸ਼ਾਰਟਫਾਰਮ ਨੂੰ ਗੈਰ-ਇਕਸੇ-ਤਰ੍ਹਾਂ ਨਕਸ਼ਾ ਕਰਦੇ ਹਨ। ਪੂਰਾ ਟਾਈਮ ਜ਼ੋਨ ID ਸਟੋਰ ਕਰੋ ਅਤੇ ਸ਼ੋਰਟਫਾਰਮਾਂ ਨੂੰ ਕੇਵਲ ਡਿਸਪਲੇ-ਸਤਰ ਤੇ ਰੱਖੋ, ਜੇ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਦਿਖਾਉਂਦੇ ਹੋ।
ਸਾਰੀ-ਦੇ-ਦਿਨ ਘਟਨਾਵਾਂ ਆਪਣੀ ਵੱਖ-ਵੱਖ ਵਰਗ ਹਨ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਸਾਰੀ-ਦੇ-ਦਿਨ ਇਵੈਂਟ ਨੂੰ "ਮਿਡਨਾਈਟ UTC" ਵਜੋਂ ਸਟੋਰ ਕਰਦੇ ਹੋ, ਤਾਂ ਨਕਾਰਾਤਮਕ ਅਫਸੈਟ ਵਾਲੇ ਖੇਤਰਾਂ ਵਿੱਚ ਉਪਭੋਗਤਾ ਇਸਨੂੰ ਪਿਛਲੇ ਦਿਨ ਹੀ ਦੇਖਣਗੇ। ਸਾਰੀ-ਦੇ-ਦਿਨ ਨੂੰ ਤਾਰੀਆਂ + ਜ਼ੋਨ ਦੇ ਨਾਲ ਸਟੋਰ ਕਰੋ।
ਕੋਡ ਰੀਵਿਊ ਲਈ ਇੱਕ ਛੋਟੀ ਚੈੱਕਲਿਸਟ:
00:00 UTC) ਵਜੋਂ ਨਾ ਸਟੋਰ ਕਰੋ।ਰਿਮਾਈਂਡਰ ਅਤੇ ਇਨਵਾਈਟ ਵੀ ਗਲਤ ਹੋ ਸਕਦੇ ਹਨ ਜਦੋਂ ਕਿ ਇਵੈਂਟ ਸਟੋਰੇਜ ਸਹੀ ਹੈ। ਉਦਾਹਰਨ: ਕੋਈ ਉਪਭੋਗਤਾ "9:00 AM Berlin time" ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ 8:45 AM Berlin time 'ਤੇ ਰਿਮਾਈਂਡਰ ਚਾਹੁੰਦਾ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਜੌਬ ਸ਼ੈਡਿਊਲਰ UTC ਵਿੱਚ ਚੱਲਦਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਗਲਤੀ ਨਾਲ "8:45" ਨੂੰ ਸਰਵਰ ਦੇ ਲੋਕਲ ਸਮਾਂ ਵਜੋਂ ਲਿਆ, ਤਾਂ ਰਿਮਾਈਂਡਰ ਜਲਦੀ ਜਾਂ ਦੇਰ ਨਾਲ ਫਾਇਰ ਹੋ ਸਕਦੇ ਹਨ।
ਕ੍ਰਾਸ-ਪਲੇਟਫਾਰਮ ਫਰਕ ਇਸਨੂੰ ਹੋਰ ਬੁਰੀ ਤਰ੍ਹਾਂ ਭੜਕਾਉਂਦੇ ਹਨ। ਇਕ ਕਲਾਈਂਟ ਅੰਬੀਗਯੂਅਸ ਸਮੇਂ ਨੂੰ ਡਿਵਾਈਸ ਜ਼ੋਨ ਦੇ ਅਧਾਰ 'ਤੇ ਵਿਆਖਿਆ ਕਰ ਸਕਦਾ ਹੈ, ਦੂਜਾ ਇਵੈਂਟ ਜ਼ੋਨ ਵਰਤਦਾ ਹੈ, ਅਤੇ ਤੀਜਾ ਕੈਸ਼ਡ DST ਨਿਯਮ ਲਗਾਉਂਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਹ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਵਰਤਾਰ ਇੱਕੋ ਜਿਹਾ ਹੋਵੇ, ਤਾਂ ਕਨਵਰਜਨ ਅਤੇ ਰਿਕਰੈਂਸ ਵਧਾਉਣਾ ਇਕੱਠੇ ਇਕ ਥਾਂ (ਅਮੂਮਨ ਸਰਵਰ) 'ਤੇ ਰੱਖੋ ਤਾਂ ਹਰ ਕਲਾਈਂਟ ਇੱਕੋ ਨਤੀਜਾ ਵੇਖੇ।
ਇੱਕ ਸਧਾਰਨ ਸਨੈਟੀ ਟੈਸਟ: DST ਬਦਲਣ ਵਾਲੇ ਹਫ਼ਤੇ ਦੌਰਾਨ ਇੱਕ ਇਵੈਂਟ ਬਣਾਓ, ਇਸਨੂੰ ਦੋ ਡਿਵਾਈਸਾਂ 'ਤੇ ਭਿੰਨ-ਭਿੰਨ ਜ਼ੋਨਾਂ 'ਤੇ ਵੇਖੋ, ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸ਼ੁਰੂਆਤੀ ਸਮਾਂ, ਤਾਰੀਖ, ਅਤੇ ਰਿਮਾਈਂਡਰ ਸਾਰੇ ਉਸ ਨਿਯਮ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ ਜੋ ਤੁਸੀਂ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਵਾਅਦਾ ਕੀਤਾ ਸੀ।
ਜ਼ਿਆਦਾਤਰ ਟਾਈਮ ਜ਼ੋਨ ਬੱਗ ਵਿਕਾਸ ਦੌਰਾਨ ਬੱਗ ਵਾਂਗ ਨਹੀਂ ਦਿੱਸਦੇ। ਉਹ ਉਸ ਵੇਲੇ ਦਰਸ ਦਿੰਦੇ ਹਨ ਜਦੋਂ ਕੋਈ ਯਾਤਰਾ ਕਰਦਾ ਹੈ, DST ਫਲਿਪ ਹੁੰਦਾ ਹੈ, ਜਾਂ ਦੋ ਲੋਕ ਸਕਰੀਨਸ਼ੌਟ ਤੁਲਨਾ ਕਰਦੇ ਹਨ।
ਪੱਕਾ ਕਰੋ ਕਿ ਤੁਹਾਡਾ ਡੇਟਾ ਮਾਡਲ ਉਸ ਤਰ੍ਹਾਂ ਦੇ ਸਮੇਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਨਿਭਾ ਰਹੇ ਹੋ। ਇਕ-ਵਾਰੀ ਦੀ ਘਟਨਾ ਨੂੰ ਇੱਕ ਸੱਚਾ ਪਲ ਚਾਹੀਦਾ ਹੈ। ਇੱਕ ਆਵਰਤੀ ਘਟਨਾ ਨੂੰ ਇੱਕ ਥਾਂ-ਅੰਕਿਤ ਨਿਯਮ ਚਾਹੀਦਾ ਹੈ।
America/New_York) ਸਟੋਰ ਕਰੋ, ਸਿਰਫ਼ ਇੱਕ ਅਫਸੈਟ ਨਹੀਂ।2026-01-16T14:00Z) ਵਿਚਕਾਰ ਸਾਫ ਫ਼ਰਕ ਰੱਖੋ।DST ਦੋ ਖਤਰਨਾਕ ਪਲ ਬਣਾਉਂਦਾ: ਮੌਜੂਦ ਨਾ ਹੋਣ ਵਾਲੇ ਸਮੇਂ (ਸਪ੍ਰਿੰਗ-ਫਾਰਵਰਡ) ਅਤੇ ਦੁਹਰਾਏ ਗਏ ਸਮੇਂ (ਫਾਲ-ਬੈਕ)। ਤੁਹਾਡੀ ਐਪ ਨੂੰ ਫੈਸਲਾ ਕਰਨਾ ਪਏਗਾ ਕਿ ਕੀ ਕਰਨਾ ਹੈ, ਅਤੇ ਇਹ ਨਿਰੰਤਰ ਤਰੀਕੇ ਨਾਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਟੈਸਟ ਸਨੇਰਿਓ: ਬਰਲਿਨ ਵਿੱਚ "ਸੋਮਵਾਰਾਂ 09:00" ਸੇਟ ਕੀਤੇ ਇੱਕ ਟੀਮ ਸਿੰਕ ਲਈ ਮਿਲਾ ਕੇ ਚੈੱਕ ਕਰੋ ਕਿ ਨਿਊਯਾਰਕ ਵਾਲੇ ਲਈ ਸਮਾਂ ਕਿਵੇਂ ਬਦਲਦਾ ਹੈ DST ਤੋਂ ਪਹਿਲਾਂ, ਅਤੇ ਫਿਰ ਯੂਐਸ ਦੇ DST ਬਦਲਣ ਤੋਂ ਬਾਅਦ।
ਬਹੁਤ سਾਰੀਆਂ ਗਲੀ-ਟਿਕਟਾਂ UI ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ ਜੋ ਟਾਈਮ ਜ਼ੋਨ ਛੁਪਾਉਂਦੀ ਹੈ। ਲੋਕ ਆਪਣੀ ਮਨਊਂਦੀ ਉਮੀਦ ਰੱਖਦੇ ਹਨ।
ਆਪਣੀ ਲੈਪਟੌਪ ਟਾਈਮ ਜ਼ੋਨ ਅਤੇ ਇੱਕ ਹੀ ਲੋਕਲ ਫਾਰਮੈਟ 'ਤੇ ਨਿਰਭਰ ਨਾ ਕਰੋ।
ਲੰਡਨ-ਆਧਾਰਿਤ ਫਾਊਂਡਰ ਇੱਕ ਹਫ਼ਤਾਵਾਰ ਸਟੈਂਡਅੱਪ ਨਿਊਯਾਰਕ ਵਾਲੇ ਟੀਮਮੀਟ ਨਾਲ ਸ਼ੈਡਿਊਲ ਕਰਦਾ ਹੈ। ਉਹ "ਮੰਗਲਵਾਰ 10:00" ਚੁਣਦੇ ਹਨ ਅਤੇ ਉਮੀਦ ਕਰਦੇ ਹਨ ਕਿ ਇਹ ਹਮੇਸ਼ਾਂ ਲੰਡਨ ਲਈ ਸਵੇਰ ਦੀ ਮੀਟਿੰਗ ਅਤੇ ਨਿਊਯਾਰਕ ਲਈ ਸ਼ੁਰੂਆਤ ਰਹੇਗੀ।
ਇੱਕ ਸੁਰੱਖਿਅਤ ਵਿਵਸਥਾ ਇਹ ਹੈ ਕਿ ਮੀਟਿੰਗ ਨੂੰ "ਹਰ ਮੰਗਲਵਾਰ Europe/London ਵਿੱਚ 10:00" ਵਜੋਂ ਟ੍ਰੀਟ ਕਰੋ, ਹਰ ਘਟਨਾ ਨੂੰ ਲੰਡਨ ਸਮੇਂ ਵਿਚ ਚੁਣੋ, ਉਸ ਘਟਨਾ ਲਈ ਅਸਲੀ ਇੰਸਟੈਂਟ(UTC) ਸਟੋਰ ਕਰੋ, ਅਤੇ ਹਰ ਦਰਸ਼ਕ ਲਈ ਉਸਨੂੰ ਉਹਨਾਂ ਦੇ ਲੋਕਲ ਸਮੇਂ ਵਿੱਚ ਦਿਖਾਓ।
ਸਪ੍ਰਿੰਗ DST ਗੈਪ ਦੇ ਆਲੇ-ਦੁਆਲੇ, ਯੂਐਸ ਘੜੀਆਂ UK ਤੋਂ ਪਹਿਲਾਂ ਬਦਲਦੀਆਂ ਹਨ:
ਆਯੋਜਕ ਲਈ ਕੁਝ ਵੀ "ਹਿੱਲਿਆ" ਨਹੀਂ। ਮੀਟਿੰਗ ਲੰਡਨ ਸਮੇਂ 10:00 'ਤੇ ਟਿਕੀ ਰਹੀ। ਸਿਰਫ਼ ਨਿਊਯਾਰਕ ਦਾ ਅਫਸੈਟ ਕਈ ਹਫ਼ਤਿਆਂ ਲਈ ਬਦਲ ਗਿਆ।
ਰਿਮਾਈਂਡਰ ਹਰ ਵਿਅਕਤੀ ਲਈ ਜੋ ਉਹ ਵੇਖਦਾ ਉਹਦੇ ਅਨੁਸਾਰ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ, ਨਾ ਕਿ ਜੋ ਉਹ ਪਹਿਲਾਂ ਵੇਖਦਾ ਸੀ। ਜੇ ਨਿਊਯਾਰਕ ਟੀਮਮੀਟ ਦਾ 15 ਮਿੰਟ ਰਿਮਾਈਂਡਰ ਹੈ, ਤਾਂ ਇਹ US ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ 05:45 'ਤੇ ਅਤੇ ਗੈਪ ਹਫ਼ਤਿਆਂ ਵਿਚ 06:45 'ਤੇ ਚਲੇਗਾ, ਬਿਨਾਂ ਕਿਸੇ ਨੇ ਇਵੈਂਟ ਸੋਧਿਆ।
ਹੁਣ ਸੋਚੋ ਸੋਧ: ਦੋ ਤੱਕਲੀਫ਼ਦਾਇਕ ਸਵੇਰਾਂ ਤੋਂ ਬਾਅਦ, ਲੰਡਨ ਆਯੋਜਕ ਅਗਲੇ ਹਫ਼ਤੇ ਤੋਂ ਸਟੈਂਡਅੱਪ ਨੂੰ 10:30 ਲੰਡਨ ਸਮੇਂ 'ਤੇ ਬਦਲਦਾ ਹੈ। ਇੱਕ ਚੰਗੀ ਸਿਸਟਮ ਇਰਾਦਾ ਬਚਾਉਂਦੀ ਹੈ: ਸੋਧ ਨੂੰ ਆਯੋਜਕ ਦੇ ਟਾਈਮ ਜ਼ੋਨ ਵਿੱਚ ਲਾਗੂ ਕਰੋ, ਭਵਿੱਖ ਦੀਆਂ ਘਟਨਾਵਾਂ ਲਈ ਨਵੇਂ UTC ਇੰਸਟੈਂਟ ਪੈਦਾ ਕਰੋ, ਅਤੇ ਪਿਛਲੀਆਂ ਘਟਨਾਵਾਂ ਨੂੰ ਜਿਵੇਂ ਸਨ ਛੱਡ ਦਿਓ।
ਵਧੀਆ ਕਾਪੀ ਸਹਾਇਤਾ ਟਿਕਟਾਂ ਰੋਕਦੀ ਹੈ: "ਹਰ ਮੰਗਲਵਾਰ 10:00 (London time). Invitees ਇਹਨਾਂ ਨੂੰ ਆਪਣੇ ਲੋਕਲ ਸਮੇਂ ਵਿੱਚ ਵੇਖਦੇ ਹਨ. ਸਮੇਂ DST ਸ਼ੁਰੂ ਜਾਂ ਖਤਮ ਹੋਣ 'ਤੇ 1 ਘੰਟਾ ਤੱਕ ਬਦਲ ਸਕਦੇ ਹਨ."
ਜ਼ਿਆਦਾਤਰ "ਟਾਈਮ ਜ਼ੋਨ ਬੱਗ" ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਉਮੀਦਾਂ ਦੀ ਗਲਤਫਹਮੀ ਹੁੰਦੀ ਹੈ। ਤੁਹਾਡਾ ਡੇਟਾ ਮਾਡਲ ਸਹੀ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਜੇ ਤੁਹਾਡੀ UI ਕਾਪੀ ਅਸਪਸ਼ਟ ਹੈ, ਲੋਕ ਸੋਚਦੇ ਹਨ ਕਿ ਐਪ ਉਹਨਾਂ ਦੀ ਸੋਚ ਪੜ੍ਹ ਲਵੇਗੀ। ਟਾਈਮ ਜ਼ੋਨ ਨੂੰ ਇਕ ਪ੍ਰੋਡਕਟ ਵਾਅਦੇ ਵਾਂਗ ਫਿਰਮਾਵੋ, ਕੇਵਲ ਇੱਕ ਬੈਕਏਂਡ ਵੇਰਵਾ ਨਹੀਂ।
ਹਰ ਜਗ੍ਹਾ ਜਿੱਥੇ ਸਮਾਂ ਦਿਖਾਈ ਦਿੱਤਾ ਜਾਵੇ ਉੱਥੇ ਉਸ ਟਾਈਮ ਜ਼ੋਨ ਦਾ ਨਾਂ ਲਿਖੋ, ਖਾਸ ਕਰਕੇ ਨੋਟੀਫਿਕੇਸ਼ਨ ਅਤੇ ਈਮੇਲ ਵਿੱਚ। "10:00 AM" ਤੇ ਹੀ ਨਿਰਭਰ ਨਾ ਕਰੋ। ਜ਼ੋਨ ਨੂੰ ਉਸਦੇ ਨਾਲ ਹੀ ਦਿਖਾਓ ਅਤੇ ਫਾਰਮੈਟ ਲਗਾਤਾਰ ਰੱਖੋ।
ਕਾਪੀ ਦੇ ਨਮੂਨੇ ਜੋ ਗੁੰਝਲ ਘਟਾਉਂਦੇ ਹਨ:
DST ਵਾਲੇ ਦਿਨਾਂ ਲਈ ਦੋਸਤਾਨਾ ਗਲਤੀ ਸੁਨੇਹੇ ਵੀ ਲੋੜੀਏ। ਜੇ ਉਪਭੋਗਤਾ ਇੱਕ ਐਸਾ ਸਮਾਂ ਚੁਣਦਾ ਹੈ ਜੋ ਮੌਜੂਦ ਨਹੀਂ (ਜਿਵੇਂ spring-forward ਰਾਤ ਨੂੰ 2:30 AM), ਤਾਂ ਤਕਨੀਕੀ ਭਾਸ਼ਾ ਤੋਂ ਬਚੋ ਅਤੇ ਵਿਕਲਪ ਦਿਓ: "2:30 AM Mar 10 ਨੂੰ ਉਪਲਬਧ ਨਹੀਂ ਕਿਉਂਕਿ ਘੜੀਆਂ ਅੱਗੇ ਵਧਦੀਆਂ ਹਨ। 1:30 AM ਜਾਂ 3:30 AM ਚੁਣੋ." ਜੇ ਇੱਕ ਸਮਾਂ ਦੂਹਰਾਇਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਸਾਫ ਪੋਚੋ: "ਕੀ ਤੁਸੀਂ ਪਹਿਲੀ 1:30 AM ਚਾਹੁੰਦੇ ਹੋ ਜਾਂ ਦੂਜੀ?"
ਸੇਫ਼ ਬਣਾਉਣ ਲਈ, ਪੂਰੇ ਫਲੋ (ਬਣਾਉਣਾ, ਇਨਵਾਈਟ, ਹੋਰ ਜ਼ੋਨ ਵਿੱਚ ਵੇਖਣਾ, DST ਤੋਂ ਬਾਅਦ ਸੋਧ) ਦਾ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾਓ ਪਹਿਲਾਂ ਕਿ ਸਕ੍ਰੀਨ ਸਨਾਰਪਿੰਗ ਕਰੋ:
ਜੇ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਇੱਕ ਸ਼ੈਡਿਊਲਿੰਗ ਫੀਚਰ ਬਣਾਉਂਦੇ ਹੋ, ਤਾਂ ਚੈਟ-ਟੂ-ਐਪ ਪਲੇਟਫਾਰਮ ਜਿਵੇਂ Koder.ai ਤੁਹਾਨੂੰ ਨਿਯਮ, ਸਕੀਮਾ, ਅਤੇ UI ਇਕੱਠੇ ਤੇਜ਼ੀ ਨਾਲ ਇਟਰੇਟ ਕਰਨ ਵਿੱਚ ਮਦਦ ਦੇ ਸਕਦਾ ਹੈ। ਗਤੀ ਵਧੀਆ ਹੈ, ਪਰ ਇਕੋ ਹੀ ਅਨੁਸ਼ਾਸਨ ਲਾਗੂ ਹੁੰਦਾ ਹੈ: ਇੰਸਟੈਂਟ ਨੂੰ UTC ਵਿੱਚ ਸਟੋਰ ਕਰੋ, ਇਵੈਂਟ ਦੇ ਇਰਾਦੇ ਲਈ IANA ਟਾਈਮ ਜ਼ੋਨ ਰੱਖੋ, ਅਤੇ ਹਮੇਸ਼ਾ ਉਪਭੋਗਤਿਆਂ ਨੂੰ ਦਿਖਾਓ ਕਿ ਉਹ ਕਿਹੜੀ ਟਾਈਮ ਜ਼ੋਨ ਦੇਖ ਰਹੇ ਹਨ।