Format tanggal JSON "benar"


1137

Saya telah melihat begitu banyak standar berbeda untuk format tanggal JSON:

"\"\\/Date(1335205592410)\\/\""         .NET JavaScriptSerializer
"\"\\/Date(1335205592410-0500)\\/\""    .NET DataContractJsonSerializer
"2012-04-23T18:25:43.511Z"              JavaScript built-in JSON object
"2012-04-21T18:25:43-05:00"             ISO 8601

Yang mana yang benar? Atau yang terbaik? Apakah ada standar dalam hal ini?


75
Tidak ada format tanggal di JSON, hanya ada satu string yang diputus / serializer untuk dipetakan ke nilai tanggal.

11
strings, numbers, true, false, null, objectsDanarrays
Russ Cam

12
Namun, objek JSON dan ISO8601 bawaan JavaScript berisi semua informasi yang dapat dipahami oleh manusia dan komputer dan tidak bergantung pada awal era komputer (1970-1-1).
poussma

Jawaban:


1849

JSON sendiri tidak menentukan bagaimana tanggal harus diwakili, tetapi JavaScript melakukannya.

Anda harus menggunakan format yang dipancarkan oleh Date's toJSONmetode:

2012-04-23T18:25:43.511Z

Inilah alasannya:

  1. Itu bisa dibaca manusia tetapi juga ringkas

  2. Jenisnya benar

  3. Ini termasuk detik fraksional, yang dapat membantu membangun kembali kronologi

  4. Sesuai dengan ISO 8601

  5. ISO 8601 telah mapan secara internasional selama lebih dari satu dekade

  6. ISO 8601 didukung oleh W3C , RFC3339 , dan XKCD

Yang sedang berkata , setiap perpustakaan tanggal yang pernah ditulis dapat memahami "milidetik sejak tahun 1970". Jadi untuk portabilitas yang mudah, ThiefMaster benar.


32
Ini juga representasi yang lebih disukai menurut ECMA :JSON.stringify({'now': new Date()}) "{"now":"2013-10-21T13:28:06.419Z"}"
Steven

11
Saya akan menambahkan alasan penting lain ke dalam daftar: ini bersifat lokal-independen. Jika Anda memiliki tanggal seperti 02-03-2014, Anda memerlukan informasi tambahan untuk mengetahui apakah ini merujuk pada tanggal 3 Februari atau 2 Maret. Itu tergantung pada apakah format AS atau format lain digunakan.
Juanal

107
upvote untuk menyebutkan dan menautkan xkcd: D @ajorquera Saya biasanya menggunakan momentjs untuk ini. Saya juga melihat masalah dengan IE dalam hal ini
fholzer

54
Mengenai poin kedua, itu tidak mengurutkan dengan benar setelah tahun 10000. Kami memiliki hampir 8000 tahun untuk datang dengan format baru, jadi mungkin itu bukan masalah.
Erfa

7
Sebenarnya, @Erfa, sejak -datang sebelum angka ASCII, itu akan baik-baik saja hingga 100.000 tahun. ; P
Ben Leggiero

128

JSON tidak tahu apa-apa tentang kencan. Apa yang dilakukan .NET adalah peretasan / ekstensi non-standar.

Saya akan menggunakan format yang dapat dengan mudah dikonversi ke Dateobjek dalam JavaScript, yaitu yang dapat diteruskan ke new Date(...). Format termudah dan mungkin paling portabel adalah cap waktu yang mengandung milidetik sejak tahun 1970.


3
stackoverflow.com/questions/10286385/… - mari kita lihat apakah ada yang tahu mengapa FF berperilaku seperti itu.
ThiefMaster

11
Jika Anda memilih rute ini, pastikan Anda tidak perlu berurusan dengan tanggal lebih awal dari tahun 1970!
Ben Dolman

8
Seperti yang dikatakan @BenDolman, "solusi" ini tidak berurusan dengan tanggal sebelum 1 Januari 1970 (Epoch). Juga, ada alasan ISO8601 ada di tempat pertama. Di Bumi ini kita memiliki hal-hal yang disebut "zona waktu". Di mana itu dalam milidetik? JSON mungkin tidak memiliki standar untuk tanggal, tapi tanggal ada di luar JSON, dan ada adalah standar untuk itu. Jawaban funroll adalah yang benar (lihat juga: xkcd.com/1179 ).
JoeLinux

5
Mungkin juga layak disebutkan bahwa (mili) detik dari tahun 1970 tidak dapat diprediksi untuk tanggal di masa depan karena kita memiliki detik kabisat . Jadi saya tidak akan menggunakannya jika untuk komunikasi antar-proses dan penyimpanan data. Namun bagus untuk digunakan secara internal dalam suatu program karena dapat disimpan dalam satu integer yang memberi Anda beberapa manfaat kinerja.
Brodie Garnet

5
Cap waktu Unix selalu UTC, Anda mengkonversi dari zona waktu lokal Anda sebelum membuat cap waktu, dan kembali lagi ke zona waktu lokal pada layar, tidak ada ambiguitas di sana.
lkraider

46

Tidak ada format yang tepat ; The JSON Spesifikasi tidak menentukan format untuk bertukar tanggal yang mengapa ada begitu banyak cara yang berbeda untuk melakukannya.

Format terbaik adalah tanggal yang direpresentasikan dalam format ISO 8601 ( lihat Wikipedia ); itu adalah format yang terkenal dan banyak digunakan dan dapat ditangani di berbagai bahasa, membuatnya sangat cocok untuk interoperabilitas. Jika Anda memiliki kontrol atas json yang dihasilkan, misalnya, Anda memberikan data ke sistem lain dalam format json, memilih 8601 karena format pertukaran tanggal adalah pilihan yang baik.

Jika Anda tidak memiliki kendali atas json yang dihasilkan, misalnya, Anda adalah konsumen json dari beberapa sistem yang ada, cara terbaik untuk menangani ini adalah memiliki fungsi utilitas penguraian tanggal untuk menangani berbagai format yang diharapkan.


2
@mlissner tapi itu pendapat yang mana yang terbaik. ISO-8601 adalah standar, tapi itu bukan standar untuk JSON (meskipun saya akan cenderung menggunakannya); misalnya, Microsoft memutuskan untuk tidak menggunakannya ( msdn.microsoft.com/en-us/library/… ). Praktik terbaik adalah tetap dengan satu konvensi (masuk akal), apa pun itu. Seperti yang saya nyatakan dalam jawaban, cara terbaik menangani ini adalah dengan menentukan fungsi utilitas parsing tanggal yang dapat menangani format yang diharapkan. Jika Anda berintegrasi dengan sistem yang menggunakan format berbeda, fungsi tersebut harus menangani setiap kasus.
Russ Cam

1
@RussCam, kita bisa bolak-balik, tetapi jika seseorang meminta cara terbaik untuk menyandikan tanggal di JSON, mereka bertanya bagaimana memformat tanggal ketika mereka membuat JSON (dan jawabannya umumnya ISO-8601). Anda menjawab pertanyaan sebaliknya: bagaimana cara mengkonsumsi tanggal JSON begitu sudah dibuat (meskipun saran Anda bagus).
mlissner

1
Spesifikasi skema JSON sebenarnya mengatakan bahwa tanggal yang diverifikasi oleh skema harus dalam format 8601.
gnasher729

3
@ gnasher729 Anda punya tautan?
Russ Cam

@vallismortis - Itu adalah spesifikasi rancangan untuk menentukan skema untuk struktur json yang diberikan yang dipertukarkan antara para pihak, bukan format untuk tanggal dalam spesifikasi json. Saya akan merevisi jawaban saya berdasarkan komentar, sepertinya tidak cukup jelas
Russ Cam

27

Dari RFC 7493 (Format Pesan I-JSON) :

I-JSON adalah singkatan dari Internet JSON atau Interonable JSON, tergantung pada siapa yang Anda tanya.

Protokol sering berisi item data yang dirancang untuk mengandung cap waktu atau jangka waktu. DIREKOMENDASIKAN bahwa semua item data tersebut dinyatakan sebagai nilai string dalam format ISO 8601, sebagaimana ditentukan dalam RFC 3339 , dengan batasan tambahan yang digunakan huruf besar daripada huruf kecil, zona waktu yang dimasukkan tidak default, dan opsional membuntuti detik dimasukkan bahkan ketika nilainya "00". DIREKOMENDASIKAN juga bahwa semua item data yang berisi durasi waktu sesuai dengan produksi "durasi" dalam Lampiran A RFC 3339, dengan batasan tambahan yang sama.


2
Ini juga merupakan format yang dihasilkan oleh Date().toISOString()dan Date().toJSON(), dengan batasan yang Datetidak melacak nilai zona waktu, dan karenanya selalu mengeluarkan cap waktu di Zzona waktu UTC ( ). Nilai dapat diuraikan menggunakan new Date("...")dan Date.parseDate.
Søren Løvborg

15

Hanya untuk referensi, saya telah melihat format ini digunakan:

Date.UTC(2017,2,22)

Ia bekerja dengan JSONP yang didukung oleh $.getJSON()fungsi. Tidak yakin saya akan merekomendasikan pendekatan ini ... hanya membuangnya di luar sana sebagai kemungkinan karena orang melakukannya dengan cara ini.

FWIW: Jangan pernah menggunakan detik sejak zaman dalam protokol komunikasi, atau milidetik sejak zaman, karena ini penuh dengan bahaya berkat implementasi acak dari detik kabisat (Anda tidak tahu apakah pengirim dan penerima sama-sama menerapkan detik kabisat UTC dengan benar).

Agak benci binatang peliharaan, tetapi banyak orang percaya bahwa UTC hanya nama baru untuk GMT - salah! Jika sistem Anda tidak menerapkan detik kabisat maka Anda menggunakan GMT (sering disebut UTC meskipun salah). Jika Anda menerapkan sepenuhnya detik kabisat Anda benar-benar menggunakan UTC. Detik lompatan di masa depan tidak dapat diketahui; mereka dipublikasikan oleh IERS seperlunya dan membutuhkan pembaruan yang konstan. Jika Anda menjalankan sistem yang mencoba menerapkan detik kabisat tetapi berisi dan tabel referensi kedaluwarsa (lebih umum daripada yang Anda kira), maka Anda tidak memiliki GMT, atau UTC, Anda memiliki sistem miring yang berpura-pura menjadi UTC.

Penghitung tanggal ini hanya kompatibel ketika dinyatakan dalam format rusak (y, m, d, dll). Mereka TIDAK PERNAH kompatibel dalam format zaman. Ingatlah itu.


4
Saya tidak akan menggunakan format itu, tetapi sisa info yang Anda berikan sangat berguna, terima kasih!
Robert Mikes

9

Jika ragu cukup buka konsol web javascript browser modern dengan menekan F12 (Ctrl + K di Firefox) dan tulis yang berikut ini:

new Date().toISOString()

Akan menghasilkan:

"2019-07-04T13: 33: 03.969Z"

Ta-da !!


3

Saya percaya bahwa format terbaik untuk interoperabilitas universal bukanlah string ISO-8601, melainkan format yang digunakan oleh EJSON:

{ "myDateField": { "$date" : <ms-since-epoch> } }

Seperti dijelaskan di sini: https://docs.meteor.com/api/ejson.html

Manfaat

  1. Kinerja parsing: Jika Anda menyimpan tanggal sebagai string ISO-8601, ini bagus jika Anda mengharapkan nilai tanggal di bawah bidang tertentu, tetapi jika Anda memiliki sistem yang harus menentukan tipe nilai tanpa konteks, Anda mengurai setiap string untuk sebuah format tanggal.
  2. Tidak Perlu untuk Validasi Tanggal: Anda tidak perlu khawatir tentang validasi dan verifikasi tanggal. Bahkan jika sebuah string cocok dengan format ISO-8601, itu mungkin bukan tanggal sebenarnya; ini tidak akan pernah terjadi dengan tanggal EJSON.
  3. Deklarasi Jenis yang Tidak Mendua: sejauh sistem data generik berjalan, jika Anda ingin menyimpan string ISO sebagai string dalam satu kasus, dan tanggal sistem nyata dalam kasus lain, sistem generik yang mengadopsi format string ISO-8601 tidak akan mengizinkan hal ini, secara mekanis (tanpa trik melarikan diri atau solusi mengerikan serupa).

Kesimpulan

Saya mengerti bahwa format yang dapat dibaca manusia (string ISO-8601) sangat membantu dan lebih nyaman untuk 80% kasus penggunaan, dan memang tidak seorang pun boleh diberi tahu untuk tidak menyimpan tanggal mereka sebagai string ISO-8601 jika itu adalah aplikasi mereka mengerti, tetapi untuk format transportasi yang diterima secara universal yang harus menjamin nilai-nilai tertentu untuk pasti tanggal, bagaimana kita dapat memungkinkan ambiguitas dan kebutuhan untuk begitu banyak validasi?


Lihat jawaban ini sebelumnya di utas mengapa milidetik sejak zaman memiliki peringatan seperti perhitungan salah detik kabisat dll: stackoverflow.com/a/42480073/190476
Sudhanshu Mishra

@SudhanshuMishra Peringatan yang Anda referensi adalah gotchas umum untuk masalah akademis yang sangat dari cap waktu unix, sebagian besar terkait dengan generasi timestamp. Ini bahkan kurang menjadi perhatian dengan resolusi milidetik. Seperti yang disebut dalam komentar lain, sebagian besar tanggal komputer secara internal direpresentasikan sebagai cap waktu unix, bahkan jika mereka diekspos dan diformat sebaliknya. Meskipun demikian, tidak ada yang salah dengan representasi milidetik dari setiap tanggal + waktu tertentu, terutama jika dibandingkan dengan pendekatan lain, yang dapat dengan mudah dipengaruhi oleh peringatan dampak nano yang sama di bawah tenda.
Ciabaros

Hanya untuk menambah kekhawatiran tentang tanggal "di luar jangkauan" untuk cap waktu unix: itu adalah masalah penyimpanan sistem, untuk ditangani dalam konteks yang jauh lebih luas daripada format transportasi. Misalnya, format ini tidak perlu terbatas pada bilangan bulat yang masuk ke dalam 32 bit, juga tidak perlu angka yang benar-benar positif, tetapi tidak ada yang akan menyelesaikan "masalah tahun 2038" dengan menjatuhkan cap waktu pada tingkat sistem / arsitektur ; mereka hanya perlu diperluas (misalnya menjadi 64-bit atau lebih), dan ini tidak mempengaruhi format transportasi yang diusulkan ini.
Ciabaros

3

JSON sendiri tidak memiliki format tanggal, tidak peduli bagaimana orang menyimpan tanggal. Namun, karena pertanyaan ini ditandai dengan javascript, saya berasumsi Anda ingin tahu cara menyimpan tanggal javascript di JSON. Anda cukup mengirimkan tanggal ke JSON.stringifymetode, dan itu akan digunakan Date.prototype.toJSONsecara default, yang pada gilirannya menggunakan Date.prototype.toISOString( MDN pada Date.toJSON ):

const json = JSON.stringify(new Date());
const parsed = JSON.parse(json); //2015-10-26T07:46:36.611Z
const date = new Date(parsed); // Back to date object

Saya juga merasa berguna untuk menggunakan reviverparameter JSON.parse( MDN di JSON.parse ) untuk secara otomatis mengkonversi kembali string ISO ke tanggal javascript setiap kali saya membaca string JSON.

const isoDatePattern = new RegExp(/\d{4}-[01]\d-[0-3]\dT[0-2]\d:[0-5]\d:[0-5]\d\.\d+([+-][0-2]\d:[0-5]\d|Z)/);

const obj = {
 a: 'foo',
 b: new Date(1500000000000) // Fri Jul 14 2017, etc...
}
const json = JSON.stringify(obj);

// Convert back, use reviver function:
const parsed = JSON.parse(json, (key, value) => {
    if (typeof value === 'string' &&  value.match(isoDatePattern)){
        return new Date(value); // isostring, so cast to js date
    }
    return value; // leave any other value as-is
});
console.log(parsed.b); // // Fri Jul 14 2017, etc...

2

Cara yang disukai menggunakan 2018-04-23T18:25:43.511Z...

Gambar di bawah ini menunjukkan mengapa ini cara yang disukai:

Tanggal JSON

Jadi seperti yang Anda lihat Date memiliki Metode asli toJSON, yang returndalam format ini dan dapat dengan mudah dikonversi Datelagi ...


2
Benar! Sintaks Interchange Data JSON tidak menentukan standar: ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf tetapi dalam praktiknya, format yang kompatibel dengan ISO 8601 lebih diinginkan di seluruh platform termasuk runtime JavaScript.
Kamyar Nazeri

1

Di Sharepoint 2013, mendapatkan data dalam JSON tidak ada format untuk mengonversi tanggal menjadi format hanya tanggal, karena pada tanggal tersebut harus dalam format ISO

yourDate.substring(0,10)

Ini mungkin bermanfaat bagi Anda


0

"2014-01-01T23: 28: 56.782Z"

Tanggal diwakili dalam format standar dan diurutkan yang mewakili waktu UTC (ditunjukkan oleh Z). ISO 8601 juga mendukung zona waktu dengan mengganti nilai Z dengan + atau - untuk offset zona waktu:

"2014-02-01T09: 28: 56.321-10: 00"

Ada variasi lain dari pengkodean zona waktu dalam spesifikasi ISO 8601, tetapi format –10: 00 adalah satu-satunya format TZ yang didukung parser JSON saat ini. Secara umum lebih baik menggunakan format berbasis UTC (Z) kecuali jika Anda memiliki kebutuhan khusus untuk mengetahui zona waktu di mana tanggal tersebut diproduksi (hanya mungkin dalam pembuatan sisi server).

NB: var date = Date baru (); console.log (tanggal); // Rabu 01 Jan 2014 13:28:56 GMT- 1000 (Waktu Standar Hawaii)

var json = JSON.stringify(date);
console.log(json);  // "2014-01-01T23:28:56.782Z"

untuk memberi tahu Anda bahwa itu cara yang disukai meskipun JavaScript tidak memiliki format standar untuk itu

// JSON encoded date
var json = "\"2014-01-01T23:28:56.782Z\"";

var dateStr = JSON.parse(json);  
console.log(dateStr); // 2014-01-01T23:28:56.782Z

0

Jika Anda menggunakan Kotlin maka ini akan menyelesaikan masalah Anda. (Format MS Json)

val dataString = "/Date(1586583441106)/"
val date = Date(Long.parseLong(dataString.substring(6, dataString.length - 2)))

-3

itu bekerja untuk saya dengan Server parse

{
    "ContractID": "203-17-DC0101-00003-10011",
    "Supplier":"Sample Co., Ltd",
    "Value":12345.80,
    "Curency":"USD",
    "StartDate": {
                "__type": "Date",
                "iso": "2017-08-22T06:11:00.000Z"
            }
}

-6

Hanya ada satu jawaban yang benar untuk ini dan sebagian besar sistem salah. Jumlah milidetik sejak zaman, alias integer 64 bit. Time Zone adalah masalah UI dan tidak memiliki bisnis di lapisan aplikasi atau lapisan db. Mengapa db Anda peduli apa zona waktu sesuatu itu, ketika Anda tahu itu akan menyimpannya sebagai integer 64 bit kemudian lakukan perhitungan transformasi.

Hapus bit yang asing dan hanya memperlakukan tanggal sebagai angka hingga UI. Anda dapat menggunakan operator aritmatika sederhana untuk melakukan kueri dan logika.



5
Sekarang Anda memiliki 2 masalah: Epoch mana yang harus Anda pilih, dan milidetik mana yang harus Anda hitung? Mungkin pilihan yang paling umum adalah waktu Unix (1970-01-01T00: 00: 00 UTC dan milidetik SI kecuali untuk mereka yang jatuh dalam detik kabisat), tetapi tentu saja yang membuat waktu masa depan tidak ditentukan.
aij

2
Jadi, bagaimana Anda mewakili mikrodetik? RFC3339 berfungsi dengan baik dengan presisi apa pun, Anda akan memiliki pembaca yang mem-parsing zona waktu dan memberi Anda cap waktu yang tepat, dan itu informasi tambahan. Aplikasi kalender biasanya peduli dengan zona waktu.
gnasher729

11
Zona waktu bukan urusan UI, kecuali Anda tidak keberatan ketinggalan penerbangan berikutnya. Penerbangan diposting pada waktu setempat dan mengikuti aturan khusus untuk perubahan DST. Kehilangan offset berarti kehilangan informasi bisnis yang penting
Panagiotis Kanavos

1
Beberapa pertentangan lebih lanjut termasuk kemampuan untuk mewakili waktu sebelum tahun 1970 (dengan asumsi zaman tertentu), dan kecenderungan JSONs agak terbaca oleh manusia.
Timo

-8

Kode berikut ini berfungsi untuk saya. Kode ini akan mencetak tanggal dalam format DD-MM-YYYY .

DateValue=DateValue.substring(6,8)+"-"+DateValue.substring(4,6)+"-"+DateValue.substring(0,4);

selain itu, Anda juga dapat menggunakan:

DateValue=DateValue.substring(0,4)+"-"+DateValue.substring(4,6)+"-"+DateValue.substring(6,8);

-19

Saya pikir itu sangat tergantung pada use case. Dalam banyak kasus mungkin lebih bermanfaat menggunakan model objek yang tepat (alih-alih merender tanggal ke string), seperti:

{
"person" :
      {
 "name" : {
   "first": "Tom",
   "middle": "M",
  ...
}
 "dob" :  {
         "year": 2012,
         "month": 4,
         "day": 23,
         "hour": 18,
         "minute": 25,
         "second": 43,
         "timeZone": "America/New_York"
    }   
   }
}

Memang ini lebih verbal daripada RFC 3339 tetapi:

  • itu dapat dibaca manusia juga
  • itu mengimplementasikan model objek yang tepat (seperti dalam OOP, sejauh JSON mengizinkannya)
  • mendukung zona waktu (bukan hanya offset UTC pada tanggal dan waktu tertentu)
  • itu dapat mendukung unit yang lebih kecil seperti milidetik, nanodetik, ... atau hanya beberapa detik
  • itu tidak memerlukan langkah parsing terpisah (untuk mengurai string tanggal-waktu), parser JSON akan melakukan segalanya untuk Anda
  • pembuatan mudah dengan kerangka kerja tanggal-waktu atau implementasi dalam bahasa apa pun
  • dapat dengan mudah diperluas untuk mendukung skala kalender lainnya (Ibrani, Cina, Islam ...) dan era (AD, SM, ...)
  • ini tahun 10000 aman ;-) (RFC 3339 tidak)
  • mendukung semua tanggal dan waktu mengambang (Javascript Date.toJSON()tidak)

Saya tidak berpikir bahwa penyortiran yang benar (seperti dicatat oleh funroll untuk RFC 3339) adalah fitur yang sangat dibutuhkan ketika membuat serial suatu tanggal ke JSON. Juga itu hanya berlaku untuk tanggal-kali memiliki offset zona waktu yang sama.


7
Saya ragu ada orang yang akan menggunakan json di tahun 10000, atau bahkan pada saat itu tahun 10000 masih akan menjadi tahun 10000. Tetapi jika kedua hal itu masih benar pada saat itu, formatnya dapat dengan mudah diperluas hingga mengandung 3 digit komponen abad. Jadi saya katakan orang dapat tetap menggunakan RFC 3339 dengan aman, setidaknya sampai tahun 9900
memori mimpi

8
@ downvoters: Menurut Mengapa pemungutan suara itu penting? Anda harus downvote jika a post contains wrong information, is poorly researched, or fails to communicate information. Tolong jelaskan salah satu dari alasan ini mengapa Anda menurunkan jawaban ini.
Marten

5
@Marten Dua hal. 1. Anda tidak pernah berhutang penjelasan untuk downvotes, meskipun saya mengerti itu bisa membantu. 2. Saya tidak meremehkan jawaban Anda, tetapi saya kira orang-orang tidak menyukai jawaban Anda karena mereka pikir itu cara yang salah untuk melakukan ini. Itu akan memenuhi syarat sebagai "Informasi yang salah" karena pertanyaannya adalah mencari cara terbaik untuk melakukan sesuatu
Kevin Wells

7
Saya tidak menurunkan suara Anda, tetapi saya tentu dapat memahami bagaimana "menemukan format lain yang tidak ditentukan dengan tepat" (yang pada dasarnya adalah apa yang Anda katakan) akan dianggap salah atau kurang diteliti.
aij

2
@ Phil, UTC sebenarnya bukan zona waktu (tidak ada tempat di bumi yang menggunakan "UTC" sebagai zona waktu resmi), ini adalah standar waktu . Juga offset zona waktu sangat tidak dapat diprediksi. Tidak ada cara untuk mengatakan jika pada tahun 2025 "12:00 waktu Moskow" masih "9:00 UTC" seperti sekarang, telah diubah beberapa kali selama 30 tahun terakhir . Jika Anda ingin mengekspresikan waktu lokal di masa mendatang, Anda perlu zona waktu yang sebenarnya.
Marten
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.