JavaScript Temporal Akan Hadir

 (developer.mozilla.org)
2 poin oleh GN⁺ 2025-01-31 | 1 komentar | Bagikan ke WhatsApp
  • Objek Temporal baru di JavaScript mulai masuk ke rilis eksperimental browser, sebagai perubahan untuk menangani tanggal, waktu, durasi, dan kalender secara lebih akurat dan konsisten melalui API bawaan
  • Date yang ada selama ini membuat penanganan zona waktu dan debugging menjadi sulit karena strukturnya berpusat pada waktu lokal pengguna dan UTC, parsing yang tidak stabil, serta perilaku mutable
  • Temporal memisahkan titik waktu, waktu lokal, dan durasi melalui Temporal.Instant, Temporal.ZonedDateTime, Temporal.PlainDateTime, Temporal.Duration, Temporal.Now, dan lainnya, serta menyediakan lebih dari 200 metode utilitas
  • Masih dibutuhkan waktu hingga dukungan lintas-browser yang stabil tersedia; di Firefox Nightly, Temporal dapat dicoba di balik pengaturan javascript.options.experimental.temporal
  • Minggu ini MDN menambahkan lebih dari 270 halaman dokumentasi Temporal, dan contoh dapat dijalankan tanpa mengubah flag di halaman dokumentasi TC39 yang menyertakan @js-temporal/polyfill

Batasan Lama JavaScript Date

  • Saat JavaScript dibuat pada 1995, objek Date menyalin implementasi awal java.util.Date milik Java; Java menggantinya pada 1997, tetapi JavaScript mempertahankan API yang sama selama hampir 30 tahun
  • Masalah terbesarnya adalah kurangnya dukungan zona waktu dan perilaku parsing yang tidak stabil
    • Hanya mendukung waktu lokal pengguna dan UTC
    • Date sendiri bersifat mutable, sehingga dapat menimbulkan bug yang sulit dilacak
    • Perhitungan yang melintasi Daylight Saving Time (DST) dan perubahan kalender historis juga sulit ditangani
  • Karena keterbatasan ini, banyak developer bergantung pada library khusus seperti Moment.js atau date-fns untuk menangani tanggal dan waktu dalam aplikasi

Model Tanggal dan Waktu yang Diubah oleh Temporal

  • Temporal dirancang sebagai pengganti penuh untuk objek Date, dengan tujuan membuat pengelolaan tanggal dan waktu lebih dapat diandalkan dan mudah diprediksi
  • Temporal mendukung representasi zona waktu dan kalender, serta menyediakan metode bawaan untuk konversi, perbandingan, perhitungan, dan formatting
  • Permukaan API-nya mencakup lebih dari 200 metode utilitas, dan dokumentasi serta contoh telah ditambahkan ke dokumentasi Temporal di MDN

Tipe Utama Temporal

  • Temporal membedakan titik waktu unik, waktu jam dinding lokal, dan durasi ke dalam tipe yang berbeda
  • Struktur utamanya adalah sebagai berikut
    • Temporal.Duration: selisih antara dua titik waktu
    • Temporal.Instant: titik waktu unik yang direpresentasikan sebagai timestamp
    • Temporal.ZonedDateTime: tanggal dan waktu yang menyertakan zona waktu
    • Temporal.PlainDateTime: tanggal dan waktu lengkap tanpa zona waktu
      • Temporal.PlainDate: hanya merepresentasikan tanggal
      • Temporal.PlainYearMonth: tahun dan bulan
      • Temporal.PlainMonthDay: bulan dan hari
      • Temporal.PlainTime: hanya merepresentasikan waktu
    • Temporal.Now: API untuk mendapatkan waktu saat ini sebagai instance berbagai class atau dalam format tertentu

Cara Penggunaan Lewat Contoh

  • Tanggal dan waktu saat ini dapat diperoleh sebagai string ISO, dan zona waktu dapat diteruskan ke berbagai metode
    • Temporal.Now.plainDateTimeISO() mengembalikan tanggal dan waktu saat ini di zona waktu sistem
    • Temporal.Now.plainDateTimeISO("America/New_York") mengembalikan tanggal dan waktu saat ini di zona waktu New York
  • Kalender selain Gregorian juga dapat ditangani, sehingga tanggal dalam sistem kalender seperti Hebrew, Chinese, dan Islamic dapat dibuat
    • Menghitung Chinese New Year berikutnya menggunakan hari pertama M01 pada kalender Chinese
    • Pada output contoh saat penulisan, Chinese New Year berikutnya adalah 1/29/2025
  • Timestamp milidetik Unix Epoch dapat diubah menjadi titik waktu dengan Temporal.Instant.fromEpochMilliseconds(), lalu dibandingkan dengan Temporal.Now.instant() untuk menghitung waktu yang tersisa
    • Untuk timestamp contoh 1851222399924, waktu dari saat ini dihitung dengan smallestUnit: "hour"
    • Output @js-temporal/polyfill adalah 31,600 hr, sedangkan output Firefox Nightly adalah PT31600H
  • toLocaleString pada implementasi Firefox saat ini tidak menghasilkan string yang sensitif terhadap locale
    • Perilaku ini lebih dekat ke keputusan desain daripada keterbatasan teknis, dan formatting duration itu sendiri tetap memungkinkan
    • Polyfill dan implementasi Firefox dapat berkonvergensi di kemudian hari
  • Metode compare() dapat digunakan untuk pengurutan array
    • Dengan durations.sort(Temporal.Duration.compare), urutannya menjadi PT1H, PT1H30M, PT1H45M, PT2H

Dukungan Browser dan Cara Mencoba

Bacaan terkait

1 komentar

 
GN⁺ 2025-01-31
Opini Hacker News

  • Temporal itu bagus. Saya sudah cukup lama memakainya di produksi lewat polyfill, dan ini menyelesaikan banyak masalah yang dulu saya alami dengan API Date()
    Rasanya seperti mengambil inspirasi dari library waktu yang bagus seperti chrono di Rust dan Joda Time di Java, lalu menggabungkannya dengan baik menjadi API yang mudah dipakai
    Memang sedikit lebih kompleks karena memisahkan waktu sederhana, titik waktu, dan waktu yang menyertakan zona waktu, tetapi waktu itu sendiri memang kompleks, jadi developer harus berhadapan dengan kompleksitas itu
    Bahkan operasi seperti “menambahkan satu hari ke timestamp ini” pun harus diputuskan apakah berdasarkan zona waktu tertentu; kalau tidak, bug akan tetap muncul karena daylight saving time, perubahan zona waktu pengguna, atau perbedaan zona waktu server
    Ini juga menyelesaikan perbedaan serialisasi antara timestamp dengan offset tetap (2025-01-01T00:00+02:00) dan zona waktu tertentu (Europe/Paris)

    • Jiff, crate Rust, juga layak dilihat. Ia terinspirasi dari Temporal, dan juga merangkum perbandingan dengan crate tanggal-waktu lain termasuk chrono: https://docs.rs/jiff/latest/jiff/_documentation/comparison/i...
      Secara pribadi, saya sulit melihat Temporal sangat terinspirasi dari chrono milik Rust; pengaruh dari Joda, java.time modern, serta library tanggal-waktu JavaScript seperti date-fns atau Moment.js tampaknya lebih besar
    • Orang-orang yang sudah cukup berumur sudah lama belajar bahwa di lingkungan produksi, jangan menjadwalkan cron job antara pukul 01:00–03:00 waktu lokal
    • Itu benar, tetapi ada satu ganjalan. Banyak orang tidak suka memakai nama zona waktu yang merujuk ke lokasi nyata
      Mereka tidak mau mencari tahu apakah Europe/Paris berarti wilayah luas di Prancis atau hanya Paris, dan merasa kesal karena seolah-olah mengatakan bahwa mereka tinggal di Paris
      Saat menjadwalkan acara komunitas online, hal seperti ini terasa menyakitkan. Orang ingin memakai offset tetap, dan ekspresi seperti CET/CEST masih dianggap oke, tetapi tidak suka sesuatu seperti Europe/yourexactcoordinates
      Sebenarnya saya tahu sebagian besar zona waktu mencakup wilayah yang cukup luas, tetapi banyak orang peduli pada privasi sekaligus tidak terpikir untuk mencari tahu perbedaan antara “waktu” dan “zona waktu”
    • chrono dan Joda Time berasal dari era yang berbeda. Saat Rust 1.0 keluar, Java sudah mengimplementasikan pendekatan ini di standard library lewat java.time, dan tidak membutuhkan library pihak ketiga untuk keperluan ini
    • Saya ingin tahu lebih detail masalah apa yang dimaksud dengan perbedaan serialisasi antara timestamp offset tetap dan timestamp zona waktu tertentu

  • Saya butuh cukup lama untuk menemukannya di dokumentasi, tetapi Temporal.ZonedDateTime.prototype.withTimeZone() mengonversi dari satu zona waktu ke zona waktu lain: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
    Nilai yang dibuat dengan Temporal.ZonedDateTime.from("2021-08-01T12:00[America/New_York]"), jika dimasukkan ke withTimeZone("Europe/Paris"), menjadi 2021-08-01T18:00:00+02:00[Europe/Paris]
    Konversi zona waktu dan penanganan durasi adalah fungsi inti yang wajib ditangani library, jadi bagus bahwa Temporal menangani keduanya. Namun di Temporal.Duration tampaknya tidak ada fungsi format kustom seperti duration.format('H\hmm\m') untuk menghasilkan 1h03m

  • Saat ini ada cukup banyak proposal yang sedang matang di TC39, dan Temporal adalah salah satu yang ingin segera dirilis
    Saya tahu bahwa agar browser utama mendukung fitur baru, diperlukan upaya pengembangan dari para engineer v8, JSC, dan SpiderMonkey, jadi saya benar-benar berterima kasih kepada orang-orang yang membuat kemajuan
    Dari sudut pandang yang tidak sabar, rasanya ingin menyemangati dengan berkata, “Records dan Tuples juga cepat dong! Perang sintaks Pipe boleh dilewati saja!”

    • Records dan Tuples tampaknya kecil kemungkinannya untuk dirilis, atau setidaknya sangat kecil kemungkinannya dirilis dengan semantik kesetaraan yang diinginkan orang
      Sejauh yang saya pahami, vendor browser pada titik ini sudah cukup kuat menentang penambahan tipe primitif baru. Kesulitan tentang bagaimana kesetaraan seharusnya bekerja dijelaskan di thread ini: https://github.com/tc39/proposal-record-tuple/issues/387
      Awalnya saya tidak menyangka BigInt akan dipakai sebanyak ini, tetapi dalam praktiknya kebutuhan akan koleksi dengan kesetaraan struktural terus muncul, jadi sayang sekali
      Saya tahu penolakan terhadap penambahan tipe primitif baru juga memengaruhi pattern matching, tetapi saya tidak begitu tahu alasannya dan tidak terlalu mengikuti proposal tersebut
    • Bagus bahwa Temporal akan hadir dan mungkin ada banyak fitur bagus lain, tetapi untuk proposal spesifik yang disebutkan tadi sulit untuk optimistis
      Pipeline, pattern matching, serta Records+Tuples semuanya sudah dikerjakan lebih dari 4 tahun dan masih tertahan di tahap 1–2. Selama setahun terakhir, hampir tidak terlihat kemajuan berarti kecuali mungkin pattern matching
      Menurut isu di repositori Records dan Tuples, ada penolakan terhadap semantik nilai, yaitu apakah === bisa berfungsi. Jika semantik nilai dihilangkan, kegunaan proposal itu akan sangat berkurang
      Agar semua ini mencapai tahap 3, setidaknya masih butuh 1–2 tahun lagi, atau mungkin tidak akan pernah sampai. Meski begitu, fungsi pengelompokan array sudah hadir
    • Yang saya inginkan adalah pattern matching: https://tc39.es/proposal-pattern-matching/
      Sayangnya masih tahap 1, jadi sepertinya masih perlu beberapa tahun lagi
    • Kalau soal Records, saya penasaran apakah Dictionary dulu merupakan proposal ECMA5 atau fitur unik AS3
      Dictionary di AS3 adalah tipe yang bisa memakai referensi objek, string, dan angka sebagai key unik, lalu menempelkan nilai bertipe apa pun. Garbage collection juga ditangani agar selama objek dictionary itu sendiri masih hidup, referensi tersebut bukan weak reference
      Bayangkan Set di JavaScript, tetapi dalam bentuk yang memakai jenis key apa pun yang ditentukan secara strongly typed dan melempar error saat compile time. Saya rindu bahasa itu
    • Ini bukan hanya masalah pembuat browser utama. Sekitar saat ES6 baru keluar, saya sedang membuat mesin inferensi JavaScript dan sudah cukup mendukung ES5, tetapi harus menyerah ketika pembaruan sintaks datang bertubi-tubi
      Pembaruan-pembaruan itu pada dasarnya merusak ekosistem JavaScript, dan sekarang rasanya yang tersisa hanya bahasa yang dikompilasi ke JS. Orang yang masih memakai vanilla JS terasa seperti orang yang membuat aplikasi dengan assembly

  • Saya penasaran bagaimana data tiap zona waktu di dalam Temporal tetap diperbarui
    Apakah strukturnya TC39 memperbarui data di suatu tempat, lalu tiap browser menyalin data itu ke dalam browser dan merilis versi baru? Dan jika pengguna belum memperbarui ke browser yang berisi data baru, apakah mereka akan melihat waktu yang salah di situs web saya?
    Misalnya, Meksiko menghapus daylight saving time pada 2022: https://en.wikipedia.org/wiki/Time_in_Mexico
    Library pihak ketiga seperti pytz atau moment-timezone cukup diperbarui di sisi server, dan jika ditangani di standard library maka versi bahasanya bisa dinaikkan, tetapi saya tidak tahu bagaimana dengan Temporal dan browser pengunjung

    • Kalau membaca “Time Zones and Resolving Ambiguity” di dokumen proposal, di sana hanya disebutkan bahwa ia memakai database zona waktu IANA, tetapi tidak dijelaskan kapan diperbarui: https://tc39.es/proposal-temporal/docs/timezone.html
      Komputer pengguna juga sepertinya bisa mengakses database ini dan menangani pembaruan, tetapi saya tidak yakin. Browser mungkin juga mengunduh dan memelihara database ini secara terpisah, dan tampaknya akan bergantung pada implementasi
      Database terkait: https://en.wikipedia.org/wiki/Tz_database
    • Karena ini fitur yang tertanam di browser, kemungkinan besar akan diperbarui saat pembaruan browser. Vendor browser telah melakukan banyak pekerjaan untuk pembaruan cepat, dan di komputer pengguna rata-rata, browser kemungkinan besar adalah software yang paling terjaga tetap mutakhir
    • Browser sudah harus menjaga locale tetap mutakhir karena helper Intl, jadi jika meneliti bagian itu kemungkinan bisa mendapatkan jawaban yang mirip
    • Sistem keluarga Unix, yaitu distribusi Linux, macOS, dan Android, memiliki salinan IANA Time Zone Database di tingkat sistem. Saya tidak begitu tahu apakah browser memakai itu atau membawa salinan sendiri, tetapi Temporal jelas memakai IANA tzdb
      Secara umum tampaknya benar bahwa jika pengguna tidak memperbarui browser atau sistem agar mencerminkan data zona waktu baru, mereka bisa melihat waktu yang salah. Namun ini tidak jauh berbeda dari praktik umum saat ini
      Alternatifnya adalah setiap aplikasi membawa tzdb sendiri; sebagian aplikasi memang begitu dan ada kasus yang sah. Namun secara umum itu pemborosan, meningkatkan ketidaksesuaian antar-aplikasi, dan kemungkinan siklus pembaruannya juga lebih lambat
    • Ini akan bergantung pada implementasi dan sistem. Implementasi pada akhirnya harus mendefinisikan penyedia zona waktu, dan kemungkinan besar itu disediakan dari hook host/sistem yang diberikan implementasi engine kepada Temporal

  • Perlu menambahkan event untuk mendeteksi ketika seseorang mengubah zona waktu
    Daftar “kebohongan yang dipercaya programmer tentang waktu” juga bisa memasukkan “programmer percaya zona waktu tetap selama penggunaan”. Kenyataannya, setiap hari jutaan orang berpindah zona waktu

    • Event seperti itu tampaknya akan dipakai sebagai titik data lain untuk fingerprinting seseorang dan memperkirakan lokasinya
    • Saya tidak begitu yakin event ini akan dipakai untuk apa. Untuk sebagian besar aplikasi web yang sedikit banyak bergantung pada waktu, melihat jumlah pengguna yang terdampak, saya ragu apakah cukup bernilai sampai harus mendengarkan event ini secara langsung dan bereaksi terhadapnya
      Tentu saja, ini bisa membantu library
    • Zona waktu klien semestinya hanya penting bagi klien. Selain untuk kenyamanan menampilkan timestamp dalam waktu lokal pengguna, tidak ada kondisi ketika jam klien menjadi penting. Tidak ada alasan untuk peduli jika pengguna mengubah zona waktunya
    • Untuk melacak perubahan zona waktu diperlukan state, jadi tampaknya lebih tepat jika developer mendefinisikan sendiri cara melacak dan meresponsnya. Mungkin kita tidak ingin Temporal punya opini tentang cara penanganannya
    • Jika berada di pesawat atau ISS, bisa saja sama sekali tidak berada dalam zona waktu apa pun

  • Sangat disayangkan .Now bukan pemanggilan fungsi. Seharusnya itu bukan properti
    Jika .Now dievaluasi beberapa kali di dalam loop, nilainya bisa berbeda setiap kali, dan ini tidak terduga
    C# juga membuat pilihan yang sama, dan seharusnya tidak: https://ericlippert.com/2014/05/19/when-should-i-write-a-pro...

    • Sepertinya ada salah paham. Now adalah namespace untuk fungsi-fungsi yang mengambil nilai aktual, misalnya seperti Now.instant()

  • Saya sangat menyukai proposal Temporal, tetapi ada satu hal yang mengganjal. Perbandingannya bergantung pada kesetaraan referensi
    Artinya Temporal.Instant.from('2020-01-01') != Temporal.Instant.from('2020-01-01')
    Ini tidak buruk pada dasarnya, tetapi secara efektif menghilangkan kemampuan untuk memakai objek-objek ini sebagai key Map atau mengumpulkannya dalam Set. Saya mengerti mengapa keputusan itu dibuat, tetapi sayang sekali bahwa itu tidak mungkin
    Mungkin suatu hari nanti, jika Records dan Tuples benar-benar hadir, akan ada versi yang berbasis pada itu

    • Apakah ada tipe non-primitif di JavaScript yang memiliki kesetaraan non-referensi pada ==?
    • Dalam beberapa situasi, .epochMilliseconds tampaknya bisa dipakai sebagai key atau elemen Map/Set. Namun, jika di Map perlu mempertahankan data zona waktu atau operasi tambahan Instant, Instant aslinya harus disimpan di sisi nilai
      Untuk Set, bisa memakai sesuatu seperti Map{v.epochMilliseconds:v} untuk mempertahankan Instant
      Tidak ideal, tetapi ini masalah yang harus disalahkan pada JavaScript itu sendiri, bukan Temporal. Runtime bisa saja dibuat menanganinya, tetapi kalau begitu polyfill akan gagal
    • Kalaupun bisa, memakai nilai seperti ini di Map/Set mirip dengan memakai angka floating-point di Map/Set, dan biasanya itu ide buruk
    • Bukankah karena ini mustahil di JavaScript? Sulit dilakukan kecuali dengan hack aneh seperti pool string konstan Java, yang membuat semua objek yang digunakan menjadi referensi ke nilai dalam pool objek global
    • Bukankah cukup memakai String() atau '2020-01-01'?

  • Menyediakan fungsi pembanding yang bekerja bersama API yang sudah ada adalah desain yang solid. Bahkan bisa dijadikan syarat wajib baca saat menambahkan tipe baru
    Misalnya, jika Temporal.Duration.compare diteruskan ke sort, urutannya bisa menjadi PT1H, PT1H30M, PT1H45M, PT2H. Salut untuk para perancangnya

  • Saya mengerti nama Temporal dimaksudkan untuk menghindari benturan dengan objek waktu umum seperti Moment atau Datetime, tetapi namanya kurang bagus
    Saat pertama melihatnya, saya kira itu semacam kontrol garbage collection

    • temporal berarti terkait waktu sebagai lawan dari keabadian, terkait tense atau pembedaan waktu dalam tata bahasa, atau terkait waktu yang dibedakan dari ruang: https://www.merriam-webster.com/dictionary/temporal
      Kedengarannya seperti nama yang cukup bagus
    • Saya kira itu adalah engine workflow Temporal di dalam browser
    • Memang ini seperti memperdebatkan warna gudang sepeda untuk keputusan yang sudah dibuat, tetapi saya setuju bahwa ini nama yang benar-benar buruk
      Pertama, Temporal itu adjektiva, bukan nomina. Memang terkait waktu, tetapi tidak terasa intuitif
      Yang lebih penting, jika memilih nama aneh demi menurunkan kemungkinan bentrok dengan kode lama, seiring waktu bahasa akan menjadi makin buram
      Saat Promise dan Generator ditambahkan, ada banyak library yang memakai nama objek itu. Berbeda dengan reserved word, objek bawaan bisa ditimpa, jadi itu bukan masalah besar
      Menurut saya komite standar seharusnya teguh memakai Time demi kesehatan jangka panjang bahasa
      Tentu saja perdebatan ini sudah berlalu, dan para pembuat browser serta implementor engine JS pasti sudah sepakat
    • Saya juga menganggapnya nama yang buruk sekali. Mungkin DateV2 malah lebih baik
      Saya mengerti perlu kompatibilitas mundur, tetapi Temporal terdengar kurang enak. DateTime juga bukan nama yang ada di standar JS, jadi saya tidak tahu mengapa mereka tidak memakai itu. Sampai saat itu, sepertinya saya akan memakai const DateTime = Temporal

  • Tulisan terkait:
    JavaScript Temporal Is Coming - https://news.ycombinator.com/item?id=42809834 - Januari 2025, 18 komentar
    Mozilla: Temporal (Limited Availability) - https://news.ycombinator.com/item?id=42776548 - Januari 2025, 1 komentar
    Is It Time for the JavaScript Temporal API? - https://news.ycombinator.com/item?id=29712118 - Desember 2021, 100 komentar
    Temporal: Getting started with JavaScript's new date time API - https://news.ycombinator.com/item?id=27661667 - Juni 2021, 194 komentar
    JavaScript Temporal - https://news.ycombinator.com/item?id=27395236 - Juni 2021, 1 komentar
    JavaScript Proposal Temporal for Dates is now stage 3 - https://news.ycombinator.com/item?id=26432346 - Maret 2021, 1 komentar

    • Memang patut disyukuri bahwa Web API belakangan ini menjadi sangat bagus, tetapi tetap disayangkan bahwa pengajuan pertama untuk topik ini sudah hampir 4 tahun lalu, pada Maret 2021
      Ungkapan bahwa kapal besar lambat berbelok memang tepat