Mga Pitfall sa Timezone ng Unix Timestamp at Paano Ito Iwasan
Dapat simple ang Unix timestamps: isang integer na kumakatawan sa mga segundo mula Enero 1, 1970 UTC. Walang timezone. Walang kalituhan. Numero lang.
Pero sa totoong mundo, laganap ang timezone-related bugs kapag humahawak ng timestamps. Lumalabas ito bilang mga event na naka-log sa maling oras, mga calendar appointment na nausog ng ilang oras, o mga database query na nagbabalik ng maling rows. Kadalasan, iisang maliit na set ng pagkakamali ang ugat nito.
Dadaan tayo sa mga karaniwang failure mode at kung paano ito iwasan. Tinutulungan ka ng Unix Timestamp Converter na i-check ang kahit anong timestamp sa UTC at local time nang magkatabi.
Bakit parang “safe” sa timezone ang timestamps — hanggang sa hindi na
Ang Unix timestamp mismo ay walang timezone. Ang 1714000000 ay iisang eksaktong sandali saan ka man. Nagkakaproblema kapag kino-convert mo ito papunta o pabalik sa human-readable na petsa/oras, dahil ang conversion na iyon ay laging may timezone — madalas implicit, at hindi mo sinadyang piliin.
Karamihan ng wika (language) ay default sa local timezone ng system kapag nagko-convert. Kung UTC ang server mo, mukhang ok ang lahat. Kung New York time, lahat ng timestamp-to-date conversion ay off ng 5 oras. Kung ang laptop ng developer ay nasa Berlin, iba ang lalabas kumpara sa CI server sa US. Consistent ang timestamp; hindi consistent ang interpretasyon.
Pitfall 1: Pagbuo ng timestamp mula sa local date strings
Ito ang pinaka-karaniwang bug. May date string ka tulad ng "2024-04-25 09:00:00" at kino-convert mo ito sa timestamp:
JavaScript: `js new Date("2024-04-25 09:00:00").getTime() / 1000 `
Python: `python from datetime import datetime datetime(2024, 4, 25, 9, 0, 0).timestamp() `
Parehong itinuturing ng mga ito ang input bilang local time. Kung nasa UTC+2 ka, ang timestamp na makukuha mo ay 07:00 UTC, hindi 09:00 UTC. Off ang timestamp mo ng 2 oras.
Ang solusyon: laging gawing explicit ang UTC.
// JavaScript — magdagdag ng Z o gumamit ng Date.UTC()
new Date("2024-04-25T09:00:00Z").getTime() / 1000
// o
Date.UTC(2024, 3, 25, 9, 0, 0) / 1000# Python — gamitin ang timezone.utc
from datetime import datetime, timezone
datetime(2024, 4, 25, 9, 0, 0, tzinfo=timezone.utc).timestamp()Mukhang maliit lang ang diperensya locally, pero sobrang sisira ito kapag tumakbo ang code sa ibang environment.
Pitfall 2: Pag-display ng timestamps nang walang tinutukoy na timezone
Baliktad naman ito ng pitfall 1. Kino-convert mo ang naka-store na timestamp pabalik sa readable date para i-display:
new Date(1714000000 * 1000).toLocaleString()
// "4/25/2024, 7:46:40 AM" (sa UTC-4)
// "4/25/2024, 1:46:40 PM" (sa UTC+2)Parehong timestamp, pero ibang oras sa ibang machine. Madalas tama ito para sa user-facing na UI (makatuwirang ipakita ang local time ng user). Pero mali ito para sa logs, audit records, API responses, at anumang kailangang consistent sa iba’t ibang system.
Para maging consistent, mag-render sa UTC o mag-specify ng timezone explicitly:
new Date(1714000000 * 1000).toISOString()
// "2024-04-25T11:46:40.000Z" — laging UTC, laging consistentfrom datetime import datetime, timezone
datetime.fromtimestamp(1714000000, tz=timezone.utc).isoformat()
# "2024-04-25T11:46:40+00:00"Pitfall 3: Daylight Saving Time (DST) sa mga boundary
Ang DST transitions ay nagdudulot ng dalawang partikular na problema.
“Nauulit na oras.” Kapag bumabalik ang oras (fall back), may isang oras na nangyayari nang dalawang beses. Kung local time ang nilolog mo at wala kang timezone info, tapos kino-convert mo ang logs sa timestamps, magiging ambiguous ang ilang entries. Ang 2:30 AM sa gabing iyon ay puwedeng unang 2:30 o pangalawa — dalawang magkaibang timestamps.
“Nilaktawang oras.” Kapag umuusad ang oras (spring forward), may isang oras na hindi umiiral sa local time. Ang scheduled job sa 2:30 AM sa gabing iyon ay puwedeng ma-trigger nang maaga, ma-late, o hindi tumakbo, depende sa scheduler.
Walang epekto nito sa Unix timestamps — tuloy-tuloy lang ang bilang ng segundo kahit may DST. Ang problema ay sa conversion sa pagitan ng timestamps at local time strings. Ang solusyon: mag-store at mag-process ng timestamps sa UTC sa buong system, at mag-convert lang sa local time sa presentation layer.
Pitfall 4: Database columns na nag-i-store ng maling format
Sa PostgreSQL, may dalawang timestamp types: TIMESTAMP WITHOUT TIME ZONE at TIMESTAMP WITH TIME ZONE (madalas TIMESTAMPTZ).
Ang TIMESTAMP WITHOUT TIME ZONE ay ini-store lang ang string na ibinigay mo at walang timezone adjustments. Kung mag-insert ka ng "2024-04-25 09:00:00" mula sa local client, iyon mismo ang mai-store — kahit 09:00 iyon sa Chicago at ang inaasahan mo ay 14:00 UTC.
Ang TIMESTAMPTZ ay nagco-convert sa UTC kapag nagsi-save, at nagco-convert pabalik sa session timezone kapag nagre-read. Karaniwan ito ang gusto mo, pero ibig sabihin, ang value na nakikita mo ay naka-depende sa SET TIME ZONE ng session.
Kung gusto mong iwasan ang ganitong complexity, puwedeng mag-store ng timestamps bilang plain integers (Unix seconds) para i-bypass ang database timezone layer. Ikaw ang may kontrol sa interpretasyon sa application layer.
May katulad na distinction din sa MySQL: DATETIME vs TIMESTAMP. Ang TIMESTAMP ay nagco-convert sa UTC sa storage at pabalik sa retrieval. Ang DATETIME ay literal na ini-store at walang timezone behavior.
Pitfall 5: Milliseconds vs seconds mismatch sa APIs
Hindi ito mismong timezone, pero nagbibigay ng kaparehong klase ng nakakalitong bug.
Ang Date.now() sa JavaScript ay milliseconds. Karamihan ng server-side languages at Unix tools ay seconds. Ang timestamp sa seconds ay karaniwang 10 digits (~1,714,000,000). Sa milliseconds, 13 digits (~1,714,000,000,000).
Kapag ang JavaScript frontend ay nagpadala ng milliseconds sa backend na nag-eexpect ng seconds, lalabas ang petsa na parang nasa taong 57,000. Kapag ang backend ay nagpadala ng seconds sa JavaScript at inakala ng frontend na milliseconds iyon, lalabas ang petsa na parang Enero 1970.
Ang Unix Timestamp Converter ay kayang hulaan ang format batay sa bilang ng digits, kaya maganda ito para sa mabilisang sanity check.
Pinakaligtas na API convention: i-document nang malinaw kung seconds o milliseconds ang ginagamit, at i-validate sa server ang incoming values. Kahit simpleng range check (i-reject ang mga petsang mas mababa sa 1970 o mas mataas sa 2100 sa UTC) ay makakahuli ng karamihan ng maling scale bago pa masira ang records.
Pitfall 6: Pag-parse ng ambiguous na date strings
Hindi lahat ng date strings ay may timezone. "April 25, 2024", "04/25/2024", "2024-04-25" — wala sa mga ito ang may timezone information. Iba-iba rin ang behavior ng parsers.
Lalo na sa JavaScript, inconsistent ito. Ang new Date("2024-04-25") ay tinatrato ang input bilang UTC midnight. Ang new Date("04/25/2024") ay tinatrato bilang local midnight. Ang ISO 8601 date-only string ang kakaibang case na hindi sumusunod sa local-default behavior.
Sa Python, ang datetime.strptime("2024-04-25", "%Y-%m-%d") ay nagbibigay ng naive datetime (walang timezone). Kapag tinawag mo ang .timestamp(), gagamit ito ng local time. Kung UTC ang environment mo, lalabas ang “tama.” Kung ibang timezone, mali.
Praktikal na rule: huwag mag-convert ng date string sa timestamp kung hindi mo alam at hindi mo explicit na tinukoy kung anong timezone ang ibig sabihin ng date string na iyon.
Isang consistent na approach para maiwasan ang lahat ng ito
Karamihan ng timezone bugs sa timestamps ay may iisang ugat: may timezone info na pumapasok o lumalabas sa system nang implicit. Ang sumusunod na convention ay halos nag-aalis ng lahat:
1. Mag-store ng timestamps sa UTC. Integer Unix seconds man o TIMESTAMPTZ sa database, panatilihing UTC sa buong system. 2. Mag-convert sa local time sa display layer lang. Huwag maagang mag-convert; gawin sa UI, gamit ang timezone preference ng user. 3. Gumamit ng ISO 8601 na may explicit offset kapag string ang ipapasa. 2024-04-25T11:46:40Z o 2024-04-25T13:46:40+02:00 — pareho itong hindi ambiguous. 4. I-validate ang scale ng incoming timestamps. I-reject ang values na magbubunga ng petsang lampas sa makatuwirang range.
Para sa one-off conversions at mabilisang sanity check, ipinapakita ng Unix Timestamp Converter ang interpretasyon sa UTC katabi ng timestamp, kaya madaling makita kung tumutugma ba ito sa inaasahang petsa.
