Petunjuk dan konteks
Sistem pemesanan global menerima “New York time 2026-11-01 01:30” lalu menampilkan dan memberi tahu peserta di zona mereka masing-masing. Menggunakan JavaScript Temporal, rancang penguraian (parsing), pengikatan zona, persistensi, dan tampilan sambil menangani waktu lokal yang tidak ada atau berulang selama transisi daylight-saving. Jangan menggabungkan semantik tanggal, waktu, dan zona menjadi satu string atau objek Date.
Apa yang sedang diuji oleh pewawancara
Sinyal yang dinilai adalah membedakan Temporal.Instant, Temporal.ZonedDateTime, Temporal.PlainDateTime, dan Temporal.PlainDate, memahami aturan IANA, ambiguitas DST, presisi, dan serialisasi. Jawaban yang kuat menjelaskan mengapa tanggal kalender bisnis tidak secara otomatis menjadi instan UTC dan bagaimana cara mempertahankan sistem kalender.
Pertanyaan klarifikasi untuk diajukan terlebih dahulu
Semantik input
Konfirmasikan apakah input berupa waktu jam dinding (wall-clock time) di zona bernama atau instan yang sudah diselesaikan, serta apakah zona tersebut berasal dari acara, organisasi, atau browser. Tanpa zona, waktu lokal bersifat ambigu.
Kebijakan ambiguitas DST
Tanyakan apakah waktu yang tidak ada atau berulang harus ditolak, memilih yang lebih awal atau lebih lambat, atau memerlukan konfirmasi. Kebijakan ini termasuk dalam kontrak produk, bukan nilai bawaan runtime yang terjadi secara tidak sengaja.
Persyaratan persistensi
Tentukan apakah pengingat adalah satu instan absolut atau berulang setiap tahun dalam kalender lokal. Pemesanan satu kali dan aturan seperti hari ulang tahun memerlukan tipe Temporal yang berbeda.
Kerangka jawaban 30 detik
“Simpan input pengguna sebagai PlainDateTime ditambah zona IANA yang eksplisit, lalu terapkan kebijakan produk untuk membuat ZonedDateTime dan Instant. Simpan Instant untuk pengingat satu kali dan konversikan ke zona masing-masing pemirsa untuk ditampilkan. Simpan tanggal lokal, waktu, zona, dan aturan kalender untuk acara berulang. Tolak atau pilih disambiguasi DST secara eksplisit dan pertahankan semantik aslinya; hindari penguraian zona lokal implisit milik Date.”
Langkah-langkah jawaban mendalam
Langkah 1: Pilih tipe data yang benar
PlainDate adalah tanggal kalender tanpa zona, PlainDateTime adalah tanggal dan waktu jam dinding tanpa zona, ZonedDateTime mengikat zona IANA, dan Instant adalah satu titik pada garis waktu. Pilih tipe data berdasarkan makna bisnis terlebih dahulu.
Langkah 2: Urai dan ikat zona
Urai input pengguna menjadi PlainDateTime, dapatkan pengidentifikasi zona tepercaya, dan gabungkan keduanya menjadi ZonedDateTime. Jangan pernah secara diam-diam menggunakan zona bawaan browser atau server sebagai zona acara.
Langkah 3: Tangani transisi DST
Spring-forward menciptakan waktu lokal yang tidak ada; fall-back menciptakan waktu lokal yang berulang. Terapkan disambiguasi eksplisit seperti menolak dan meminta pengguna mengonfirmasi ulang, atau memilih yang lebih awal/lebih lambat jika persyaratannya memungkinkan. Catat pilihan tersebut bersama pemesanan.
Langkah 4: Konversikan ke instan pengingat
Untuk pemesanan satu kali, dapatkan Instant dari ZonedDateTime dan simpan string yang telah dinormalisasi. Jadwalkan berdasarkan Instant; konversikan ke zona pemirsa hanya pada saat tampilan alih-alih menginterpretasikan ulang teks jam dinding asli.
Langkah 5: Pertahankan semantik acara berulang
Acara tahunan pada pukul 09:00 lokal tidak dapat disimpan sebagai satu offset UTC karena DST mengubah offset tersebut. Simpan PlainDate, PlainTime, zona IANA, dan sistem kalender, lalu selesaikan ZonedDateTime baru untuk setiap kemunculan.
Langkah 6: Tentukan presisi dan kalender
Tentukan apakah milidetik, mikrodetik, atau nanodetik diperlukan; jangan memotongnya selama serialisasi sehingga merusak pengurutan. Untuk kalender bisnis non-ISO, simpan pengidentifikasi kalender alih-alih memperlakukan tanggalnya sebagai tanggal ISO.
Langkah 7: Uji skenario batas
Cakup spring-forward dan fall-back, batas tahun, tahun kabisat, pembaruan basis data zona waktu, perbedaan lokal, dan siklus serialisasi round-trip. Lakukan assertion pada instan, tampilan lokal, dan aturan pengulangan secara terpisah alih-alih hanya membandingkan string.
Contoh jawaban berkualitas tinggi
Saya akan mengurai input sebagai PlainDateTime, mewajibkan zona IANA, dan menerapkan kebijakan DST eksplisit untuk membuat ZonedDateTime. Simpan Instant untuk pengingat satu kali dan konversikan untuk setiap pemirsa; simpan tanggal lokal, waktu, zona, dan aturan kalender untuk perulangan serta selesaikan instan baru setiap kali terjadi. Pengujian mencakup waktu yang tidak ada dan berulang, tahun kabisat, pembaruan basis data zona, dan presisi. Ini menghindari perilaku zona implisit dari Date.
Kesalahan umum
- Kesalahan: Memperlakukan
PlainDateTimesebagai UTC. → Mengapa: Tipe ini tidak memiliki semantik zona. → Perbaikan: Ikat zona IANA eksplisit terlebih dahulu. - Kesalahan: Hanya menyimpan offset UTC untuk acara tahunan. → Mengapa: DST mengubah offset lokal. → Perbaikan: Simpan waktu lokal dan aturan zona.
- Kesalahan: Mengabaikan waktu yang berulang saat fall-back. → Mengapa: Satu waktu jam dinding memetakan ke dua instan. → Perbaikan: Tolak atau pilih lebih awal/lebih lambat secara eksplisit.
- Kesalahan: Hanya memvalidasi kesamaan string. → Mengapa: String tidak membuktikan semantik instan atau kalender. → Perbaikan: Lakukan assertion pada perilaku Instant, ZonedDateTime, dan perulangan secara terpisah.
Pertanyaan lanjutan dan jawaban
Pertanyaan lanjutan 1: Kapan Anda harus menyimpan Instant?
Ketika acara tersebut berarti satu kejadian absolut pada garis waktu, seperti mengirimkan pengingat atau mencatat pembayaran. Zona pemirsa mengubah penyajian, bukan instannya.
Pertanyaan lanjutan 2: Mengapa hari ulang tahun tidak boleh disimpan sebagai Instant?
Hari ulang tahun adalah tanggal kalender lokal, biasanya bukan satu instan yang terjadi secara serempak di seluruh dunia. Simpan tanggal, zona, dan aturan kalender, lalu hitung instan untuk setiap kemunculan.
Pertanyaan lanjutan 3: Bisakah pembaruan basis data zona waktu memengaruhi pemesanan yang disimpan?
Ya. Aturan waktu lokal di masa mendatang dapat berubah. Pertahankan zona dan semantik asli, catat versi aturan jika diperlukan, dan tentukan bagaimana penghitungan ulang ditangani.
Pertanyaan lanjutan 4: Apakah Temporal secara otomatis menentukan ambiguitas DST?
API menyediakan opsi disambiguasi, tetapi produk harus memilih perilaku tolak, lebih awal, lebih lambat, atau kompatibel. Opsi bawaan bukanlah kebijakan bisnis.