Gesaan dan konteks
Sistem tempahan global menerima “New York time 2026-11-01 01:30” dan memaparkan serta memberitahu peserta dalam zon masing-masing. Menggunakan JavaScript Temporal, reka bentuk penghuraian, pengikatan zon, ketahanan data (persistence) dan paparan sambil mengendalikan masa tempatan yang tidak wujud atau berulang semasa peralihan waktu jimat siang (daylight-saving). Jangan runtuhkan semantik tarikh, masa dan zon menjadi satu rentetan atau objek Date.
Perkara yang diuji oleh penemu duga
Isyarat yang dinilai ialah membezakan Temporal.Instant, Temporal.ZonedDateTime, Temporal.PlainDateTime dan Temporal.PlainDate, memahami peraturan IANA, ketaksaan DST, kejituan dan penyirikan (serialization). Jawapan yang mantap menjelaskan sebab tarikh kalendar perniagaan bukan secara automatik merupakan detik UTC dan cara mengekalkan sistem kalendar.
Soalan penjelasan untuk ditanya terlebih dahulu
Semantik input
Sahkan sama ada input adalah masa jam dinding dalam zon yang dinamakan atau detik yang telah diselesaikan, dan sama ada zon itu datang daripada acara, organisasi atau pelayar. Tanpa zon, masa tempatan adalah taksa.
Polisi ketaksaan DST
Tanya sama ada masa yang tidak wujud atau berulang harus ditolak, memilih yang lebih awal atau lebih lewat, atau memerlukan pengesahan. Polisi ini adalah milik kontrak produk, bukan lalai masa jalan (runtime) yang tidak disengajakan.
Keperluan ketahanan data (persistence)
Tentukan sama ada peringatan ialah satu detik mutlak atau berulang setiap tahun dalam kalendar tempatan. Tempahan sekali sahaja dan peraturan seperti hari lahir memerlukan jenis Temporal yang berbeza.
Rangka kerja jawapan 30 saat
“Kekalkan input pengguna sebagai PlainDateTime ditambah zon IANA yang eksplisit, kemudian gunakan polisi produk untuk mencipta ZonedDateTime dan Instant. Kekalkan Instant untuk peringatan sekali sahaja dan tukarkannya kepada zon setiap pelihat untuk paparan. Kekalkan tarikh, masa, zon dan peraturan kalendar tempatan untuk acara berulang. Tolak atau pilih penyahtaksaan DST secara eksplisit dan kekalkan semantik asal; elakkan penghuraian zon tempatan tersirat oleh Date.”
Langkah jawapan mendalam
Langkah 1: Pilih jenis yang betul
PlainDate ialah tarikh kalendar tanpa zon, PlainDateTime ialah tarikh dan masa jam dinding tanpa zon, ZonedDateTime mengikat zon IANA dan Instant ialah satu titik pada garis masa. Pilih jenis daripada makna perniagaan terlebih dahulu.
Langkah 2: Hurai dan ikat zon
Hurai input pengguna kepada PlainDateTime, dapatkan pengecam zon yang dipercayai dan gabungkannya menjadi ZonedDateTime. Jangan sesekali menggunakan zon lalai pelayar atau pelayan secara senyap sebagai zon acara.
Langkah 3: Kendalikan peralihan DST
Lompatan ke hadapan pada musim bunga (spring-forward) mencipta masa tempatan yang tidak wujud; pengunduran pada musim luruh (fall-back) mencipta masa tempatan yang berulang. Gunakan penyahtaksaan eksplisit seperti menolak dan meminta pengesahan semula daripada pengguna, atau memilih lebih awal/lebih lewat apabila keperluan membenarkannya. Catat pilihan tersebut bersama tempahan.
Langkah 4: Tukar kepada detik peringatan
Untuk tempahan sekali sahaja, dapatkan Instant daripada ZonedDateTime dan kekalkan rentetan yang dinormalkan. Jadualkan mengikut Instant; tukarkannya kepada zon pelihat hanya pada masa paparan dan bukannya mentafsir semula teks jam dinding yang asal.
Langkah 5: Kekalkan semantik acara berulang
Acara tahunan pada 09:00 tempatan tidak boleh disimpan sebagai satu imbangan UTC kerana DST mengubah imbangan tersebut. Kekalkan PlainDate, PlainTime, zon IANA dan sistem kalendar, kemudian selesaikan ZonedDateTime baharu untuk setiap kejadian.
Langkah 6: Tentukan kejituan dan kalendar
Nyatakan sama ada milisaat, mikrosaat atau nanosaat diperlukan; jangan memotong (truncate) semasa penyirikan dan merosakkan susunan. Untuk kalendar perniagaan bukan ISO, kekalkan pengecam kalendar dan bukannya menganggap tarikhnya sebagai tarikh ISO.
Langkah 7: Uji sempadan
Kendalikan kes spring-forward dan fall-back, sempadan tahun, tahun lompat, kemas kini pangkalan data zon masa, perbezaan lokal dan kitaran ulang-alik penyirikan (serialization round trips). Lakukan penegasan (assert) pada detik, paparan tempatan dan peraturan keberulangan secara berasingan dan bukannya membandingkan rentetan semata-mata.
Contoh jawapan berkualiti tinggi
Saya akan menghuraikan input sebagai PlainDateTime, memerlukan zon IANA dan menggunakan polisi DST yang eksplisit untuk mencipta ZonedDateTime. Kekalkan Instant untuk peringatan sekali sahaja dan tukarkannya untuk setiap pelihat; kekalkan tarikh, masa, zon dan peraturan kalendar tempatan untuk keberulangan serta selesaikan detik baharu setiap kali. Ujian merangkumi masa yang tidak wujud dan berulang, tahun lompat, kemas kini pangkalan data zon dan kejituan. Ini mengelakkan tingkah laku zon tersirat oleh Date.
Kesilapan lazim
- Kesilapan: Menganggap
PlainDateTimesebagai UTC. → Sebab: Ia tidak mempunyai semantik zon. → Penambahbaikan: Ikat zon IANA yang eksplisit terlebih dahulu. - Kesilapan: Hanya mengekalkan imbangan UTC untuk acara tahunan. → Sebab: DST mengubah imbangan tempatan. → Penambahbaikan: Kekalkan masa tempatan dan peraturan zon.
- Kesilapan: Mengabaikan masa fall-back yang berulang. → Sebab: Satu masa jam dinding memetakan kepada dua detik. → Penambahbaikan: Tolak atau pilih secara eksplisit lebih awal/lebih lewat.
- Kesilapan: Hanya mengesahkan kesamaan rentetan. → Sebab: Rentetan tidak membuktikan semantik detik atau kalendar. → Penambahbaikan: Tegaskan tingkah laku Instant, ZonedDateTime dan keberulangan secara berasingan.
Soalan susulan dan jawapan
Soalan susulan 1: Bilakah anda patut mengekalkan Instant?
Apabila acara tersebut bermaksud satu kejadian mutlak pada garis masa, seperti menghantar peringatan atau merekodkan pembayaran. Zon pelihat menukar persembahan paparan, bukan detik tersebut.
Soalan susulan 2: Mengapakah hari lahir tidak patut disimpan sebagai Instant?
Hari lahir ialah tarikh kalendar tempatan, biasanya bukan satu detik yang berlaku serentak di seluruh dunia. Simpan tarikh, zon dan peraturan kalendar, kemudian kira detik bagi setiap kejadian.
Soalan susulan 3: Bolehkah kemas kini pangkalan data zon masa mempengaruhi tempahan yang disimpan?
Ya. Peraturan masa tempatan pada masa hadapan boleh berubah. Kekalkan zon dan semantik asal, rekodkan versi peraturan apabila diperlukan dan tentukan cara pengiraan semula dikendalikan.
Soalan susulan 4: Adakah Temporal secara automatik menentukan ketaksaan DST?
API menyediakan pilihan penyahtaksaan, tetapi produk mesti memilih sama ada tingkah laku tolak, lebih awal, lebih lewat atau serasi. Pilihan lalai bukanlah polisi perniagaan.