Baru-baru ini, saya sedang mengerjakan tugas menambahkan zona waktu ke perpustakaan kalender JS yang dikelola oleh tim saya. Saya sangat menyadari dukungan zona waktu yang tidak berguna dalam JavaScript, tetapi saya berharap bahwa abstrak objek data yang ada akan membuatnya mudah untuk menyelesaikan sebagian besar kesulitan.
Namun, mimpi saya menjadi debu. Ketika saya mempelajari tugas itu, saya menyadari bahwa sangat sulit untuk bekerja dengan zona waktu dalam bahasa ini. Sangat sulit untuk mengimplementasikan sesuatu yang lebih rumit daripada sekadar memformat tampilan waktu dan menghitung tanggal menggunakan operasi kompleks (fungsi kalender). Saya mendapatkan pengalaman berharga dalam memecahkan masalah ini, dan ini memerlukan kesulitan baru.
Pada artikel ini saya ingin membahas apa yang saya temukan dan bagaimana menyelesaikannya. Sementara saya menulis teks, saya menyadari bahwa alasan semua kesulitan adalah pemahaman saya yang buruk tentang topik zona waktu. Mengingat kesadaran ini, saya mengusulkan pertama untuk berbicara secara rinci tentang definisi dan standar, dan baru kemudian beralih ke JavaScript.
Apa itu zona waktu?
Zona waktu adalah wilayah geografis yang menggunakan waktu lokal yang sama yang ditetapkan oleh pemerintah. Banyak negara terkait sepenuhnya dengan zona waktu tertentu, dan di wilayah negara-negara besar, seperti Rusia dan Amerika Serikat, beberapa zona waktu digunakan. Sangat mengherankan bahwa meskipun Cina juga cukup besar, ia hanya menerima satu zona waktu. Terkadang ini mengarah pada situasi aneh ketika matahari terbit di bagian barat negara itu dimulai sekitar jam 10 pagi.
GMT, UTC dan Offset
GMT
Waktu lokal Korea Selatan ditetapkan sebagai
GMT+09:00 . GMT adalah singkatan dari Greenwich Mean Time (GMT), yaitu kali ini di jam Royal Observatory di Greenwich, Inggris. Terletak di meridian utama. Sinyal radio sistem GMT mulai mengudara pada 5 Februari 1924, dan itu sendiri berubah menjadi standar dunia pada 1 Januari 1972.
UTC
Banyak orang berpikir bahwa GMT dan UTC adalah hal yang sama, sering menggunakannya sebagai sistem yang dapat dipertukarkan. Tapi ini sebuah kesalahan. Sistem UTC muncul pada tahun 1972 sebagai cara untuk mengkompensasi efek rotasi Bumi. Sistem ini didasarkan pada Waktu Atom Internasional, dihitung dengan frekuensi getaran elektromagnetik atom cesium. Dengan kata lain, UTC adalah pengganti yang lebih akurat untuk GMT. Walaupun perbedaan waktu nyata antara kedua sistem sangat kecil, lebih baik bagi pengembang perangkat lunak untuk mengandalkan UTC.
Fakta menarik: ketika UTC masih dikembangkan, disarankan di negara-negara berbahasa Inggris untuk menyebutnya CUT (Waktu Universal Terkoordinasi), dan di negara-negara berbahasa Prancis - TUC (Temps Universal Coordonn). Namun, tidak ada kamp yang bisa menang, dan mereka sepakat untuk memanggil sistem UTC, ejaan dari kedua opsi yang diusulkan (C, T dan U).
Offset
+09:00 dalam
UTC+09:00 berarti waktu setempat adalah 9 jam lebih awal dari waktu UTC standar. Yaitu, ketika jam 9 malam di Korea Selatan, itu siang di wilayah UTC. Perbedaan antara waktu UTC standar dan waktu lokal disebut "offset", yang dinyatakan sebagai nilai positif atau negatif:
+09:00 ,
-03:00 , dll.
Di banyak negara, sudah lazim untuk memberi zona waktu nama unik kepada Anda. Sebagai contoh, zona waktu Korea Selatan disebut KST (Waktu Standar Korea), offsetnya dinyatakan sebagai
KST = UTC+09:00 . Namun, offset
+09:00 digunakan tidak hanya oleh Korea Selatan, tetapi juga oleh Jepang, Indonesia, dan banyak negara lain, oleh karena itu, hubungan antara offset dan sabuk dinyatakan bukan sebagai 1: 1, tetapi sebagai 1: N. Daftar negara dengan offset
+09:00 disajikan di
sini .
Beberapa offset beroperasi tidak hanya selama berjam-jam. Misalnya, di Korea Utara, waktu standar adalah
+08:30 , sementara di Australia di beberapa daerah
+8:45 ,
+09:30 dan
+10:30 .
Daftar lengkap offset UTC ada di
sini .
Zona Waktu! == offset?
Seperti yang saya katakan, kami menggunakan nama zona waktu (KST, JST) dengan offset sebagai dipertukarkan, tanpa membedakan di antara mereka. Tetapi akan keliru untuk mempertimbangkan waktu yang sama dan pergeseran wilayah tertentu. Ada beberapa alasan:
Daylight Saving Time (DST)
Di beberapa negara, istilah ini tidak diketahui, tetapi di banyak negara, waktu musim panas dipraktekkan, terutama di Eropa. Untuk ini, istilah internasional DST diadopsi - Daylight Saving Time. Ini berarti menggerakkan jam di musim panas selama satu jam lebih cepat dari waktu standar relatif.
Misalnya, California menggunakan PST (Waktu Standar Pasifik) di musim dingin dan PDT (Waktu Siang Pasifik,
UTC-07:00 ) di musim dingin. Di Amerika Serikat dan Kanada, istilah Waktu Pasifik (PT, Waktu Pasifik) digunakan untuk wilayah yang menggunakan dua zona waktu.
Kapan waktu musim panas mulai dan berakhir? Itu semua tergantung negara. Misalnya, di AS dan Kanada hingga 2006, DST digunakan mulai jam 2 pagi pada hari Minggu pertama bulan April hingga jam 12 pagi pada hari Minggu terakhir bulan Oktober. Dan sejak 2007, waktu musim panas mulai dihitung dari 2 malam pada hari Minggu kedua bulan Maret hingga 2 malam pada hari Minggu pertama bulan November. Di Eropa, berbagai negara mempraktikkan penggunaan progresif DST tergantung pada setiap zona waktu.
Apakah zona waktu berubah?
Setiap negara sendiri menentukan zona waktu mana yang akan digunakan, sehingga waktu setempat dapat berubah karena alasan politik dan / atau ekonomi. Misalnya, di Amerika Serikat, perbatasan DST diubah pada 2007 karena George W. Bush memulai kebijakan energi pada 2005. Mesir dan Rusia digunakan untuk beralih ke waktu musim panas, tetapi telah meninggalkannya sejak 2011.
Dalam beberapa kasus, pemerintah dapat mengubah tidak hanya waktu musim panas, tetapi juga waktu standar. Sebagai contoh, Samoa sebelumnya menggunakan offset
UTC-10:00 , tetapi kemudian mereka beralih ke
UTC+14:00 untuk mengurangi kerugian dalam perdagangan karena perbedaan waktu dengan Australia dan Selandia Baru. Keputusan ini menyebabkan hilangnya nyawa negara sepanjang hari - 30 Desember 2011, seperti dilansir
surat kabar di seluruh dunia .
Di Belanda, offset
+0:19:32.13 digunakan sejak 1909, sejak 1937 negara tersebut beralih ke
+00:20 , dan dari 1940 hingga
+01:00 , sejak saat itu waktu utama tidak berubah di sana.
Zona Waktu 1: Offset N
Jadi, zona waktu dapat memiliki satu atau lebih offset. Waktu mana yang diterima sebagai standar tergantung pada alasan politik dan / atau ekonomi saat ini di negara tertentu.
Dalam kehidupan sehari-hari, ini tidak menimbulkan kesulitan sampai Anda mencoba mensistematisasikan data ini berdasarkan beberapa aturan. Bayangkan Anda ingin mengatur waktu standar pada ponsel cerdas Anda menggunakan semacam bias. Jika Anda tinggal di wilayah yang menerapkan waktu musim panas, maka ponsel cerdas Anda harus tahu persis kapan harus bolak-balik. Artinya, Anda perlu membangun hubungan antara waktu standar dan musim panas dalam satu zona waktu (misalnya, Waktu Pasifik).
Tetapi ini tidak dapat dilakukan dengan beberapa aturan sederhana. Misalnya, ketika di AS pada 2007, awal dan akhir DST diubah, pada 31 Mei 2006 ia seharusnya menggunakan PDT (
-07:00 ) sebagai waktu standar, dan pada 31 Maret 2007 - PST (
-08:00 ). Ternyata untuk merujuk ke zona waktu tertentu, Anda perlu mengetahui seluruh sejarah perubahan zona waktu atau tanggal perubahan aturan waktu musim panas.
Anda dapat mengatakan: "Zona waktu di New York adalah PST (
-08:00 )." Namun, perlu diklarifikasi: "Zona waktu saat ini di New York adalah PST." Selain itu, untuk implementasi sistem yang akurat, Anda perlu menggunakan ekspresi yang lebih akurat. Lupakan istilah "zona waktu". Anda harus mengatakan: "Sekarang di New York, PST digunakan sebagai waktu standar."
Jadi apa yang harus kita gunakan daripada offset untuk menentukan zona waktu suatu wilayah tertentu? Nama wilayah ini. Lebih tepatnya, Anda harus mengelompokkan dalam satu zona waktu satu wilayah di mana mereka beralih sama ke musim panas dan waktu standar. Anda dapat menggunakan nama seperti PT (Waktu Pasifik), tetapi mereka hanya menggabungkan waktu standar saat ini dan waktu musim panas, dan tidak selalu memperhitungkan semua perubahan historis. Selain itu, karena PT hanya beredar di Amerika Serikat dan Kanada, Anda harus mengandalkan standar yang ditetapkan dari organisasi terkemuka untuk memastikan universalitas perangkat lunak Anda.
Database Zona Waktu IANA
Saya harus mengakui bahwa informasi tentang zona waktu lebih merupakan basis data, bukan seperangkat aturan, karena informasi ini harus mengandung semua perubahan historis yang relevan. Ada beberapa database standar yang dirancang untuk menyelesaikan tugas yang berkaitan dengan zona waktu. Paling sering,
Basis Data Zona Waktu IANA digunakan , dan biasanya disebut basis data tz (atau tzdata). Basis data berisi data historis tentang perubahan waktu standar dan DST di seluruh dunia. Selain itu, ini diatur sehingga memungkinkan untuk memeriksa semua data historis dan memastikan waktu akurat mulai dari waktu Unix (
1970.01/01 00:00:00 ). Meskipun Anda dapat menemukan informasi dalam database bahkan sebelum tahun 1970, keakuratannya tidak dijamin.
Konvensi penamaan menggunakan aturan wilayah / tempat. Nama benua atau lautan (Asia, Amerika, Samudra Pasifik) biasanya digunakan sebagai wilayah, dan nama-nama kota utama (Seoul, New York) sebagai tempat. Alasannya adalah bahwa kota biasanya lebih lama dari negara. Misalnya, zona waktu Korea Selatan adalah
Asia/Seoul dan Jepang
Asia/Tokyo . Meskipun kedua negara menggunakan offset
UTC+09:00 , waktu lokal mereka berubah secara berbeda, sehingga mereka dibagi ke dalam zona waktu yang berbeda.
Basis IANA dijalankan oleh banyak komunitas pengembang dan sejarawan. Data historis yang baru ditemukan segera dimasukkan ke dalamnya dan kebijakan saat ini diperbarui, sehingga database saat ini dapat dianggap sebagai sumber yang paling dapat diandalkan. Selain itu, ini digunakan di bawah tenda oleh banyak sistem Unix, termasuk Linux dan MacOS, serta sejumlah bahasa pemrograman populer, termasuk Java dan PHP.
Harap dicatat bahwa Windows menggunakan
database Microsoft . Namun, itu tidak akurat dalam hal data historis dan hanya didukung oleh Microsoft sendiri. Oleh karena itu, basisnya kurang dapat diandalkan dibandingkan dengan basis IANA.
JavaScript dan IANA
Fungsionalitas terkait zona waktu diimplementasikan dalam JavaScript secara tiba-tiba. Secara default, bahasa tersebut menggunakan sabuk wilayah saat ini (lebih tepatnya, sabuk yang dipilih selama instalasi OS), dan tidak ada cara untuk mengubahnya. Selain itu, bahkan spesifikasi untuk standar basis data dalam JavaScript tidak jelas, dan Anda sendiri akan memahami ini jika Anda memutuskan untuk berurusan dengan spesifikasi untuk ES2015. Tentang zona waktu lokal dan ketersediaan DST, hanya ada beberapa pernyataan yang tidak jelas. Sebagai contoh, DST didefinisikan sebagai berikut:
ECMAScript 2015 - Penyesuaian Waktu Siang Hari .
Ini adalah algoritme yang bergantung pada implementasi yang menggunakan informasi zona waktu terbaik yang tersedia untuk menentukan pengaturan DaylightSavingTA (t) waktu siang hari lokal, yang dihitung dalam milidetik. Implementasi ECMAScript akan membantu Anda menentukan pengaturan waktu musim panas lokal yang lebih baik.
Sepertinya mereka hanya berkata, "Dudes, cobalah untuk membuatnya bekerja." Antara lain, Anda harus menyelesaikan masalah kompatibilitas dengan browser yang berbeda. Anda berkata, "Benar-benar kacau!" Dan kemudian bacalah baris berikut:
Catatan: kami sarankan Anda menggunakan informasi dari basis data zona waktu IANA http://www.iana.org/time-zones/ dalam implementasi Anda.
Ya Spesifikasi ECMA memberi Anda bola dengan rekomendasi bersahaja untuk menggunakan basis data IANA, karena JavaScript tidak memiliki basis data standar khusus. Akibatnya, browser yang berbeda menggunakan operasi mereka sendiri dengan zona waktu, yang sering tidak kompatibel satu sama lain, untuk menghitung waktu. Kemudian, di ECMA, untuk API internasional, opsi untuk menggunakan data IANA dalam format ECMA-402
Intl.DateTimeFormat . Tetapi opsi ini jauh lebih tidak dapat diandalkan daripada analog dalam bahasa pemrograman lain.
Zona waktu di lingkungan server-klien
Pertimbangkan skenario sederhana: kita perlu menentukan zona waktu. Misalkan kita membuat kalender yang akan memproses informasi waktu. Ketika pengguna di lingkungan klien memasukkan tanggal dan waktu di jendela registrasi, tanggal tersebut ditransfer ke server dan disimpan dalam database. Kemudian klien menerima dari server tanggal yang terdaftar dalam jadwal untuk ditampilkan di layar.
Di sini Anda perlu memutuskan sesuatu. Bagaimana jika beberapa klien yang mengakses server berada di zona waktu yang berbeda? Acara dalam jadwal, yang didaftarkan di Seoul pada 10 Maret 2017 pukul 23.30, di New York harus ditampilkan sebagai 10 Maret 2017 pukul 9.30. Agar server dapat melayani klien dari zona waktu yang berbeda, jadwal yang disimpan di dalamnya harus berisi nilai absolut yang tidak bergantung pada zona. Setiap server memiliki cara sendiri untuk menyimpan nilai-nilai tersebut, pertanyaan ini berada di luar cakupan artikel, karena semuanya tergantung pada server atau database tertentu. Secara umum, tanggal dan waktu yang ditransmisikan dari klien ke server harus disajikan baik dalam bentuk nilai berdasarkan pada offset tunggal (biasanya UTC), atau dalam bentuk nilai yang berisi informasi tentang zona waktu lingkungan klien.
Biasanya, data tersebut dikirim sebagai
waktu Unix dalam format UTC atau sesuai dengan standar
ISO-8601 dengan informasi offset. Jika dalam contoh kami, kami mengonversi Seoul 21.30 pada 10 Maret 2017 ke waktu Unix, maka kami mendapatkan nilai integer
1489113000 . Dan dalam format ISO-8601, nilai string adalah
2017–03–10T11:30:00+09:00 .
Jika Anda menggunakan JavaScript di lingkungan peramban, Anda harus mengonversi nilai yang dimasukkan seperti yang dijelaskan di atas, lalu mengonversi kembali untuk mencocokkan zona waktu pengguna. Penting untuk menyelesaikan kedua masalah ini. Dari sudut pandang bahasa pemrograman, operasi pertama disebut "parsing", dan yang kedua adalah "pemformatan". Sekarang mari kita lihat bagaimana hal ini dilakukan dalam JavaScript.
Bahkan ketika Anda bekerja dengan JS di lingkungan server menggunakan Node.js, Anda mungkin perlu mengurai data yang diterima dari klien. Tetapi karena zona waktu server dan database biasanya disinkronkan, dan pemformatan ditugaskan untuk klien, dalam lingkungan browser Anda perlu memutuskan beberapa faktor. Lebih lanjut saya akan menjelaskan sehubungan dengan lingkungan browser.
Objek Tanggal JavaScript
Tugas yang melibatkan pekerjaan dengan waktu atau waktu tertentu diselesaikan dengan menggunakan objek
Date . Ini adalah objek asli yang didefinisikan dalam ECMAScript, seperti
Array atau
Function . Artinya, sebagian besar, diimplementasikan menggunakan kode asli seperti C ++. API dijelaskan dengan baik dalam
dokumentasi MDN . Kelas
java.util.Date dari Java memiliki dampak besar pada objek, sehingga mewarisi beberapa properti yang tidak diinginkan, seperti karakteristik data yang bisa berubah dan satu bulan mulai dari nol.
Di bawah tenda, objek
Date JavaScript bekerja dengan waktu menggunakan nilai absolut dalam format waktu-Unix. Tetapi konstruktor dan metode seperti fungsi
parse() ,
getHour() ,
setHour() dan lainnya dipengaruhi oleh zona waktu klien (lebih tepatnya, sabuk yang ditentukan dalam OS di mana browser berjalan). Jadi, jika Anda membuat objek
Date secara langsung menggunakan data yang dimasukkan pengguna, maka zona waktu lokal klien akan tercermin dalam data ini.
Seperti yang saya sebutkan, JavaScript tidak memberikan cara apa pun untuk mengubah zona waktu secara sewenang-wenang. Karenanya, kami menganggap bahwa kami dapat langsung menggunakan nilai zona waktu yang ditentukan di browser.
Membuat Objek Tanggal Menggunakan Input Pengguna
Mari kita kembali ke contoh pertama. Misalkan seorang pengguna memasukkan waktu Seoul pada perangkatnya pada jam 11.30 pada tanggal 11 Maret 2017. Data ini disimpan sebagai lima angka: 2017, 2, 11, 11 dan 30 - masing-masing tahun, bulan, hari, jam dan menit (sejak bulan dimulai dari 0, itu nilainya harus 3-1 = 2). Menggunakan konstruktor, Anda dapat dengan mudah membuat objek
Date :
const d1 = new Date(2017, 2, 11, 11, 30); d1.toString();
Jika Anda melihat nilai yang dikembalikan oleh
d1.toString() , Anda akan melihat bahwa nilai absolut dari objek yang dibuat adalah 11:00 pada 11 Maret 2017, itu dihitung menggunakan pencampuran
+09:00 (KST).
Anda dapat menggunakan data string di konstruktor. Jika Anda menerapkannya ke
Date , objek memanggil
Date.parse() internal dan
Date.parse() benar. Fitur ini mendukung
spesifikasi RFC2888 dan
ISO-8601 . Tetapi
dokumentasi MDN untuk Date.parse () mengatakan bahwa nilai yang dikembalikan oleh metode ini tergantung pada browser, dan format tipe string dapat memengaruhi nilai akhir yang tepat. Karena itu, lebih baik tidak menggunakan metode ini. Misalnya, di Safari dan Internet Explorer, nilai string seperti
2015–10–12 12:00:00 mengembalikan
NaN , sementara di Chrome dan Firefox mengembalikan nilai zona waktu lokal. Dalam beberapa situasi, nilai berbasis UTC dikembalikan.
Membuat Objek Tanggal Menggunakan Data Server
Misalkan Anda ingin menerima data dari server. Jika mereka dalam bentuk waktu Unix numerik, maka Anda cukup menggunakan konstruktor untuk membuat objek
Date . Saya belum menyebutkan bahwa ketika konstruktor
Date menerima nilai tunggal sebagai parameter tunggal, itu menghitung nilai waktu Unix dalam milidetik (catatan: JS memproses waktu Unix dalam milidetik. Ini berarti bahwa nilai kedua harus dikalikan dengan 1000). Saat menjalankan kode berikut, kami mendapatkan nilai yang sama seperti pada contoh sebelumnya:
const d1 = new Date(1489199400000); d1.toString();
Dan jika bukan waktu Unix gunakan tipe string ISO-8601? Seperti yang saya jelaskan di atas, maka metode
Date.parse() menjadi tidak dapat diandalkan dan lebih baik tidak menggunakannya. Namun, dimulai dengan ECMAScript 5, Anda dapat menggunakan konstruksi string dalam format ISO-8601 di konstruktor
Date di Internet Explorer 9.0 dan lebih tinggi.
Jika Anda tidak menggunakan browser terbaru, maka pastikan
Z di akhir nilai. Tanpanya, browser lama Anda dapat menginterpretasikan nilai berdasarkan waktu setempat, bukan UTC. Berikut adalah contoh penggunaan di Internet Explorer 10:
const d1 = new Date('2017-03-11T11:30:00'); const d2 = new Date('2017-03-11T11:30:00Z'); d1.toString();
Menurut spesifikasi, dalam kedua kasus nilai yang sama harus diperoleh. Tetapi mereka berbeda. Di browser yang lebih baru, nilainya akan sama. Untuk mencegah masalah ini, selalu tambahkan
Z di akhir baris jika informasi zona waktu tidak tersedia.
Membuat Tanggal untuk Lulus ke Server
Sekarang Anda dapat menggunakan
Date dibuat sebelumnya, dengan bebas mengambil atau menambah waktu berdasarkan zona waktu setempat. Hanya pada akhir pemrosesan jangan lupa untuk mengkonversi data ke format sebelumnya sebelum mengembalikannya ke server.
Jika ini waktu Unix, Anda dapat menggunakan metode
getTime() (jangan lupa tentang milidetik).
const d1 = new Date(2017, 2, 11, 11, 30); d1.getTime();
Bagaimana dengan nilai string dalam format ISO-8601? Seperti yang saya katakan, Internet Explorer 9.0 dan di atasnya mendukung ECMAScript 5, dan versi yang lebih baru mendukung ISO-8601. Oleh karena itu, menggunakan metode
toISOString() atau
toJSON() , Anda dapat membuat string di ISO-8601 (
toJSON() dapat digunakan untuk panggilan rekursif dengan
JSON.stringify() dan lainnya). Kedua metode memberikan hasil yang sama, kecuali saat memproses data yang tidak valid:
const d1 = new Date(2017, 2, 11, 11, 30); d1.toISOString();
Anda dapat menggunakan metode
toGMTString() atau
toUTCString() untuk membuat string UTC. Ini akan menghasilkan nilai yang sesuai dengan
RFC-1123 .
Objek
Date termasuk
toString() ,
toLocaleString() dan metode ekstensi mereka. Tetapi mereka sedikit berguna, karena mereka digunakan terutama untuk mengembalikan string berdasarkan zona waktu lokal, dan nilai yang dikembalikan tergantung pada browser dan OS.
Ubah zona waktu lokal Anda
Seperti yang Anda lihat, ada semacam dukungan zona waktu di JS. ? ? , JS . , . . , .
. . 11.30 11 2017 - . Unix- , -
-05:00 . , .
getTimeZoneOffset() . API JavaScript, . :
const seoul = new Date(1489199400000); seoul.getTimeZoneOffset();
-540 , 540 . , (
+09:00 ). , , . -,
60 * 5 = 300 .
840 Date .
getXX . :
function formatDate(date) { return date.getFullYear() + '/' + (date.getMonth() + 1) + '/' + date.getDate() + ' ' + date.getHours() + ':' + date.getMinutes(); } const seoul = new Date(1489199400000); const ny = new Date(1489199400000 - (840 * 60 * 1000)); formatDate(seoul);
formatDate() -. , . , ? , . , — , . ( ).
, . , -, 11 15 .
setDate() Date , , .
ny.setDate(15); formatDate(ny);
, . , ? ,
getTime() getISOString() . , .
const time = ny.getTime() + (840 * 60 * 1000);
, , .
Date ? Tidak.
Date 11- 15-, 4 (
24 * 4 * 60 * 60 * 1000 ). - 10- 15-, 5 (
24* 5 * 60 * 60 * 1000 ). .
. , . - 12 , 15 2017
-04:00 ,
-05:00 . , 780 , 60 , .
const time = ny.getTime() + (780 * 60 * 1000);
, - , .
, . , , , . , ,
IANA .
,
Date , . , . , . . JS . .
Moment Timezone
Moment — JavaScript-, . API , .
Moment Timezone , . IANA API, .
. , .
.
, Moment Timezone:
const seoul = moment(1489199400000).tz('Asia/Seoul'); const ny = moment(1489199400000).tz('America/New_York'); seoul.format();
seoul ,
ny -05:00 -04:00 .
format() , ISO-8601, . .
Kesimpulan
API , JavaScript, . , API, Internet Explorer 9 . , . ,
getTimezoneOffset() . , . Moment Timezone.
, , . : . , , , . , JavaScript . , .