Kes Edge dalam Pembangunan Apl dan Bahagian Belakang — Tarikh & Masa

pengenalan

Anda mungkin berfikir bahawa berurusan dengan tarikh dan masa adalah mudah. Kami mempunyai satu minit yang berlangsung 60 saat, satu jam dengan 60 minit, sehari dengan 24 jam, seminggu dengan 7 hari, sebulan dengan 28 hingga 31 hari, dan seterusnya.

Pastinya tiada sains roket diperlukan di sini…

Nah, tiada apa yang lebih jauh daripada kebenaran!

Kami akan menunjukkan perangkap dan perangkap yang berkaitan dengan tarikh dan masa yang mungkin anda hadapi semasa pembangunan aplikasi dan bahagian belakang.

Unit ukuran

Mari kita mulakan dengan unit ukuran, daripada yang terkecil kepada yang terbesar.

Saat dan milisaat

Unit terkecil yang digunakan setiap hari ialah satu saat. Ia juga merupakan asas masa Unix.

Walau bagaimanapun, dalam sesetengah bahasa pengaturcaraan, seperti Java, unit yang paling biasa ialah milisaat (1/1000 detik), seperti kaedah System.currentTimeMillis(), contohnya.

Percanggahan itu boleh membawa kepada banyak kesilapan.

Jika anda menerima nilai berangka dari luar sistem anda, pada pandangan pertama mungkin tidak jelas unit ukuran yang digunakan, walaupun selepas membaca dokumentasi!

Lihat medan DATE dalam lajur pembekal kandungan SMS dan MMS (pangkalan data). Kedua-dua dokumen hanya menyatakan:

• Tarikh mesej diterima.

• Jenis: INTEGER (panjang)

Walau bagaimanapun, SMS menggunakan milisaat manakala MMS menggunakan saat. Terkejut? Nah, ini mungkin berlaku, terutamanya jika API sedemikian direka oleh orang yang berbeza.

Bagaimana anda boleh menangani kes seperti ini? Dan bagaimana anda boleh mengelakkannya?

Nasib baik, kami boleh merumuskan beberapa peraturan am:

1. Sentiasa pastikan format data masuk.
   Semak di alam liar kerana dokumentasi mungkin tidak betul dan/atau ketinggalan zaman. Ia biasanya sangat mudah untuk mengesan ralat, seperti tarikh 50 ribu tahun terlalu jauh pada masa hadapan, apabila anda mencarinya semasa membangun. Hasil ini berlaku apabila milisaat dianggap sebagai saat, contohnya.

2. Jika anda mempunyai apa-apa pengaruh di pihak yang menghantar nilai (cth. sistem sedang direka bentuk dan tiada sesiapa menggunakannya lagi), pertimbangkan format teks piawai.
   Di sini, saya menekankan penyeragaman (cth.ISO 8601) bukan beberapa format tersuai (kami akan meluaskan topik ini kemudian). Selepas beberapa tahun, tiada sesiapa daripada pasukan asal mungkin lagi bekerja untuk projek itu, dan format teks adalah mudah untuk difahami untuk pembangun baharu, kerana mereka tidak perlu melihat dokumen.
   Format berangka mungkin lebih baik, walau bagaimanapun, dalam peralatan kritikal prestasi.

3. **Gunakan kelas khusus untuk menangani nilai tarikh/masa/tempoh berbanding integer mentah.
   **Dalam dunia Java, kami mempunyai pakej java.time dengan banyak kelas berguna seperti Instant atau Duration. Jika terdapat integer dipanggil cth. EventDuration, tidak diketahui sama ada ia menyimpan saat atau milisaat - atau mungkin beberapa hari?

4. Jika anda mesti berurusan dengan nilai mentah (integer, longs dll.) yang anda tidak boleh hanya memfaktorkan semula sepenuhnya, seperti kod warisan, serta unit ukuran dengan nama pembolehubah/medan .
   Contohnya,eventDurationSeconds tidak jelas.

Detik lompat

Anda mungkin pernah mendengar tentang tahun lompat. Mereka berbeza daripada yang "biasa" dengan menjadi hari tambahan lebih lama. Kami juga mempunyai detik lompat!

Adakah ia lebih lama daripada saat bukan lompat?

Nah, ia bergantung!

Pertama, mari kita mulakan dengan sedikit teori. Bumi semakin perlahan; sebenarnya ia bukanlah kenyataan falsafah tetapi fakta yang terbukti secara saintifik. Ia dipanggil delta-T.

OK, jadi apakah maksud ini dalam amalan untuk kita? Nah, unit ukuran kami untuk masa mempunyai panjang piawai. Unit asas ialah satu saat, yang ditakrifkan sebagai:

Tempoh masa 9 192 631 770 tempoh sinaran yang sepadan dengan peralihan antara dua tahap hiperhalus keadaan asas yang tidak terganggu bagi atom caesium-133. (sumber: bipm.org)

Tempoh itu adalah malar, dan memaklumkan semua unit lain yang diperoleh daripada saat cth. seminit terdiri daripada 60 saat, satu jam ialah 60 minit (3,600 saat) dan seterusnya.

Walau bagaimanapun, jika Bumi menjadi perlahan (dan hari semakin lama), kita perlu entah bagaimana menampung kelembapan itu untuk memastikan masa yang diukur oleh unit kita adalah konsisten dengan realiti. Ini dilakukan dengan memasukkan saat tambahan — saat lompat.

Hanya terdapat 2 slot yang tersedia untuk saat lompat dalam tahun ini: penghujung bulan Jun dan Disember. Penghujungnya bermaksud hari terakhir (masing-masing ke-30 atau ke-31) selepas 23:59:59 UTC (jadi waktu tempatan berbeza-beza).

Selepas detik terakhir biasanya, detik lompat tambahan dimasukkan sebelum bergerak ke hari berikutnya. Jadi, kita boleh mempunyai 23:59:60 (61 saat dalam seminit — seperti yang kita kira dari‌ 0).

Disebabkan oleh fakta bahawa kelembapan tidak tetap, saat lompat dimasukkan secara tidak teratur. Yang terbaru (ketika menulis artikel ini pada April 2021) berlaku pada Disember 2016, iaitu lebih daripada 4 tahun yang lalu. Walau bagaimanapun, yang terakhir adalah pada Jun 2015, dengan hanya perbezaan 1.5 tahun antara kedua-duanya.

Di sesetengah tempat di mana kita boleh menetapkan masa — seperti jam dinding fizikal atau beberapa API rangka kerja, mungkin tiada keupayaan untuk memerhati dan/atau menetapkan masa dengan detik lompat.

Sebagai contoh, kelas Date Java yang lama menyokong bahkan dua saat lompat — julat merebak dari 0 hingga 61, jadi 62 saat mungkin!

Walau bagaimanapun, kelas Segera moden daripada pakej java.time tidak mendedahkan detik lompat kepada pengaturcara. Lompatan kedua diregangkan sama sepanjang 1,000 saat terakhir hari itu (saat itu lebih panjang).

Perhatikan bahawa, secara teori, detik lompat boleh juga negatif. Tetapi ia tidak berlaku setakat ini.

Ini bermakna seminit boleh terdiri daripada 59 saat, yang mungkin membawa kepada isu besar. Sebagai contoh, jika beberapa tindakan dijadualkan berlaku pada 23:59:59.001 dan ternyata masa yang diingini tidak wujud…

Nasib baik secara analog untuk menyebarkan detik yang boleh dilihat juga mungkin dikecilkan kerana telus sepenuhnya kepada pengaturcara.

Kita tahu detik ke-61 boleh wujud, tetapi bagaimana pula dengan detik ke-62? Nah, dokumentasi mengatakan:

Kemungkinan besar dua saat lompat akan berlaku dalam minit yang sama, tetapi spesifikasi ini mengikut konvensyen tarikh dan masa untuk ISO C.

Memang, dalam spesifikasi C kami mempunyai julat [0, 61]. Tapi kenapa? Soalan yang sama mengganggu Paul Eggert, pengarang tzdata (pangkalan data zon waktu) pada tahun 1992. Seperti yang boleh kita baca dalam arkib:

*“Kerana terdapat dua saat lompat dalam satu tahun (pada hari yang berasingan), dan seseorang dalam jawatankuasa ANSI C berpendapat bahawa mereka datang pada hari yang sama.” *— sumber groups.google.com.

Ralat tafsiran kecil itu, yang berlaku beberapa dekad yang lalu, masih kelihatan sekarang kerana pelaksanaan baharu perlu serasi ke belakang dengan piawaian ini.

Mari pergi ke kes tepi lain dalam pembangunan apl dan bahagian belakang.

hari-hari

Minit dan waktu tidak melibatkan sebarang kes yang tidak dijangka jadi mari kita beralih ke hari.

Apa itu hari? Ia bergantung! Anda boleh mengatakan bahawa ia berlangsung selama 24 jam dari 00:00:00 hingga 23:59:60 (termasuk detik lompat ? ). Baiklah, sama ada yang terakhir ini secara amnya benar, hari itu tidak selalunya berlangsung 24 jam, kerana ia mungkin 23, 25 atau 21 dan 27! Mengapa nilai-nilai tersebut? Jawapannya ialah…

Waktu penjimatan siang

Apa yang dipanggil DST atau "masa musim panas" memajukan jam pada bulan yang lebih panas bertujuan untuk mengurangkan penggunaan kuasa. Kegelapan bermula lewat daripada masa "biasa" (bukan DST). Pada masa kini, keperluan DST boleh dipertikaikan kerana terdapat banyak keburukan. Sesetengah negara telah berhenti memerhati DST baru-baru ini (cth. Rusia pada 2014) disebabkan oleh mereka.

Apakah masalah DST? Jom tengok!

Saya tidak akan membincangkan perkara seperti terlupa pelarasan jam dinding secara manual atau pengangkutan awam yang tertunda tetapi sebaliknya, saya akan menumpukan pada aspek yang berkaitan dengan bahagian belakang dan pembangunan apl.

Anda mungkin berfikir bahawa, pada waktu musim panas, kami memajukan jam sebanyak 1 jam. Ini tidak selalu berlaku! Terdapat tempat di dunia yang perbezaannya ialah 3 jam (seperti Casey) atau 30 minit (seperti Pulau Lord Howe).

Masa musim panas, tidak tepat seperti namanya, juga boleh meliputi beberapa bahagian musim bunga atau musim luruh tetapi, secara amnya, ia berkaitan dengan bulan-bulan yang lebih panas. Sebaliknya, itu bergantung pada hemisfera.

Sementara di Eropah ada musim panas, di Australia ada musim sejuk dan begitu juga sebaliknya. Jadi, untuk meletakkannya dalam perspektif, waktu musim panas Australia berlaku semasa musim sejuk Eropah!

Apatah lagi, takrifan musim panas dari segi masa bergantung pada bidang kuasa. Di semua negara Kesatuan Eropah, masa ditukar pada masa yang sama jadi perbezaan masa antara Berlin dan London, sebagai contoh, sentiasa 1 jam, tidak kira sama ada kita berada di musim panas atau musim sejuk.

Tetapi mari kita pertimbangkan perbezaan masa antara Sydney dan London. Dalam kes ini, ia bergantung pada hari dalam setahun! Ini kerana Sydney mula dan berhenti memerhati DST pada tarikh yang berbeza daripada London.

Inspirasi: timeanddate.com

Contohnya, mulai Januari kita ada perbezaan 10 jam. Sydney memerhati DST pada masa itu tetapi London tidak. Pada akhir bulan Mac, London mula memerhatikan DST, manakala negeri di Sydney kekal tidak berubah, jadi perbezaannya berkurangan kepada 9 jam. Kemudian pada bulan April, Sydney berhenti memerhati DST, jadi kami mempunyai 8 jam. Kami mempunyai 3 offset yang berbeza. Jadi soalan tentang perbezaan masa antara Sydney dan London mempunyai 3 jawapan!

Negara seperti AS, ahli EU atau Australia mempunyai, katakan, bidang kuasa yang stabil berkenaan dengan DST. Ia diketahui lebih awal apabila peralihan berlaku. Walau bagaimanapun, ia tidak selalu berlaku, kerana sesetengah negara mungkin mengubah undang-undang secara tidak dijangka. Contohnya pada tahun 2020 di Fiji, peraturan telah berubah dengan pengumuman hanya tiba beberapa bulan sebelum ini.

Malah situasi yang lebih rumit berlaku di beberapa negara Islam yang menyambut Ramadan secara rasmi. Jika mereka juga mematuhi DST, yang terakhir mungkin… digantung (untuk tempoh Ramadan).

Ini bermakna peralihan DST mungkin berlaku lebih daripada sekali (bolak-balik) malah beberapa kali dalam setahun. Tambahan pula, Ramadan dikira mengikut kalendar Islam (lunar). Ramalan digunakan untuk mengira tarikh sempadan Ramadan dan ia mungkin tidak selalu tepat. Sebagai contoh, di Palestin pada tahun 2020, ramalan ternyata pendek kira-kira seminggu. Perubahan telah digunakan hanya beberapa hari lebih awal.

Kebanyakan sistem menggunakan pangkalan data Zon Masa IANA sebagai sumber detik peralihan DST. Biasanya terdapat beberapa kemas kini setiap tahun dalam pangkalan data itu.

Perhatikan bahawa berurusan dengan DST mungkin mempunyai kesan pada algoritma. Mari kita pertimbangkan beberapa senario biasa.

Jika kita mempunyai penggera yang dijadualkan pada masa dinding tertentu (cth. 02:30) mungkin ternyata detik sedemikian tidak wujud (apabila masa ditukar dari 02:00 hingga 03:00 semasa peralihan DST) atau ia wujud dua kali apabila masa diubah ke belakang. Jika, sebagai contoh, sandaran tidak akan dilakukan atau ubat tidak akan diberikan atau akan diberikan dua kali, maka akibatnya mungkin mengerikan.

Satu lagi kesan biasa terdiri daripada perubahan masa pencetus kitaran jika pengguna berada di zon waktu memerhati DST. Contohnya, jika anda menjadualkan binaan pada bitrise.io untuk dipecat pada pukul 10:00, ia mungkin mula menembak secara tiba-tiba pada pukul 11:00.

Ini berlaku kerana logik di bawah hud tidak mengetahui DST dan masa yang boleh dilihat oleh pengguna hanya dikira semasa memaparkan UI. Detik masa mutlak sentiasa sama tetapi masa yang boleh dilihat oleh pengguna berubah bergantung pada DST. Biasanya, ia bukan seperti yang pelanggan harapkan.

minggu-minggu

Apakah hari pertama dalam seminggu? Jika anda tinggal di Eropah, anda mungkin akan mengatakan hari Isnin. Di Amerika Syarikat ia akan menjadi hari Ahad dan di negara Arab - Sabtu. Fakta ini mungkin memberi kesan kepada pembinaan dan/atau pemaparan kalendar algoritma.

Bagaimana dengan nombor minggu dalam tahun itu? Anda mungkin berfikir bahawa semuanya bermula dari 1 Januari.

Seperti yang anda mungkin sangka, ini juga tidak selalu berlaku!

Mengikut standard ISO, minggu pertama dalam setahun mesti mengandungi hari Khamis. Sebagai contoh, pada 2021 1 Januari adalah pada hari Jumaat jadi ia tergolong dalam minggu terakhir tahun sebelumnya. Minggu pertama 2021 bermula pada 4 Januari! Tidak semua tempat menggunakan peraturan yang sama seperti standard ISO dalam perkara itu, walau bagaimanapun.

Bulan-bulan

Kalendar Gregorian yang digunakan oleh kebanyakan dunia mempunyai 12 bulan, dari Januari hingga Disember. Walau bagaimanapun, jenis kalendar lain mungkin mempunyai lebih banyak bulan. Contohnya kalendar Ibrani mungkin mempunyai 13 bulan. Yang ke-13 (dalam dunia IT) dipanggil Undecimber.

Tahun-tahun

Biasanya, tahun ini berlangsung selama 365 hari. Walau bagaimanapun, setiap satu boleh dibahagikan dengan 4 (cth. 2020, 2024 dsb.) ialah tahun lompat yang mempunyai 366 hari (dengan 29 hari pada bulan Februari dan bukannya 28 biasa). Tetapi, jika ia boleh dibahagikan dengan 100 (2100, 2200 dsb.) ia BUKAN tahun lompat. Tetapi ? jika ia boleh dibahagi dengan 400 (2000, 2400 dsb.) ia adalah tahun lompat.

Nasib baik, anda tidak perlu (dan tidak sepatutnya!) cuba melaksanakan perbezaan tersebut sendiri. Anda harus menggunakan kelas/fungsi tarikh pustaka terkenal bagi bahasa pengaturcaraan yang diberikan.

Terdapat banyak pepijat yang menakjubkan dalam perkhidmatan terkenal yang berkaitan dengan pengiraan tahun lompat yang salah. Malah ada istilah: Masalah tahun lompat.

Zon waktu

Waktu tempatan bergantung pada longitud. Walaupun waktu tengah hari di lokasi tertentu, ia juga tengah malam di seberang dunia.

Adalah tidak praktikal untuk melaraskan jam secara berterusan semasa melakukan perjalanan, jadi dunia dibahagikan kepada zon yang meliputi kawasan yang mempunyai waktu rasmi tempatan yang sama.

Sempadan zon biasanya sama dengan sempadan negara dalam kes negara kecil atau beberapa kawasan geografi di kawasan terbesar (seperti Australia, Amerika Syarikat atau Rusia).

Sumber: timeanddate.com

Atas sebab politik dan ekonomi di sesetengah tempat, waktu rasmi berbeza dengan ketara daripada masa "sah" (hanya mengambil kira masa longitud/matahari). Sebagai contoh, di Sepanyol, zon adalah sama seperti di kebanyakan benua Eropah tengah berbanding United Kingdom, yang lebih dekat mengikut longitud.

Kebanyakan zon waktu mempunyai offset kamiran (perbezaan daripada UTC — masa standard) cth. di Berlin +1 jam (+2 dalam DST) atau -3 jam di Buenos Aires (Argentina, tiada DST). Walau bagaimanapun, ofset mungkin termasuk setengah jam cth. di Mumbai (India) kami mempunyai +5:30j (tiada DST).

Jika itu tidak mencukupi, suku juga boleh dilakukan, kerana di Kathmandu (Nepal) kami mempunyai +5:45j!

Nasib baik, tiada lagi offset yang lebih halus pada masa penulisan. Walau bagaimanapun, ia pernah wujud pada masa lalu, seperti +0:20 di Belanda.

Disebabkan fakta bahawa kami mempunyai 24 jam pada jam, seseorang mungkin berfikir bahawa ia juga merupakan julat kemungkinan offset. +12:00 dan -12:00 digabungkan bersama memberikan 24.

Walau bagaimanapun, jarak masa paling jauh antara zon waktu ialah 26 jam!

Ini mungkin kerana kami mempunyai offset +14:00. Ia diterima pakai oleh beberapa negara di Oceania kerana mereka agak berhubung dengan Australia, jadi lebih praktikal untuk mempunyai perbezaan beberapa jam berbanding lebih daripada 20, yang membawa kepada tarikh lain dalam kebanyakan kes.

Mari pertimbangkan pencari sambungan penerbangan. Dalam kes penerbangan pergi balik, pengguna boleh memilih tarikh/masa berlepas dan pulang. Mungkin nampak jelas bahawa masa balik mestilah selepas berlepas.

Sudah tentu, ini tidak boleh jauh dari kebenaran!

Perlu diingat bahawa masa tersebut berada dalam zon waktu tempatan.

Sila lihat contoh ini:

1. Bertolak dari Tokyo pada 00:30 (offset +09:00) ke San Francisco (offset -07:00)

2. Ketibaan di San Francisco pada jam 18:00, hari sebelumnya dalam waktu tempatan!

3. Pulang dari San Francisco pada pukul 19:50 (masih sebelumnya apabila berbanding dengan pelepasan awal)

Jadi, anda boleh pergi ke suatu tempat dan kembali semalam. Lihat contoh ini:

Penamaan zon waktu

Satu lagi kes kelebihan berpotensi dalam pembangunan apl/belakang yang mungkin anda hadapi disambungkan kepada penamaan zon waktu.

Anda mungkin perasan bahawa kami boleh memanggil zon waktu dengan mengimbanginya cth. +01:00 atau dengan pengecamnya cth. Eropah/Berlin. Ambil perhatian bahawa notasi yang terakhir memberikan pelbagai faedah: ia membawa maklumat tentang peralihan DST (Berlin mempunyai offset +02:00 pada musim panas) dan ia juga menyimpan data sejarah.

Sebagai contoh, kedua-dua zon Eropah/Warsaw dan Eropah/Berlin nampaknya sama pada masa kini. Kedua-duanya mempunyai offset yang sama sepanjang tahun, dengan peralihan DST juga sentiasa berlaku pada saat yang sama.

Walau bagaimanapun, ia tidak selalu berlaku pada masa lalu! Contohnya, pada tahun 1977 tidak ada DST di Berlin sama sekali tetapi Warsaw memerhatikannya dari 3 April hingga 25 September (berbeza sama sekali daripada apa yang kita ada hari ini).

Perhatikan bahawa pengecam zon waktu dibina berdasarkan nama bandar. Ini disengajakan kerana sempadan negara tertakluk kepada perubahan lebih kerap daripada nama bandar.

Sebagai contoh, Crimea sebenarnya telah bertukar dari Ukraine kepada Rusia tetapi nama bandar tidak berubah. Zon Eropah/Simferopol boleh digunakan tidak kira sama ada kita memerlukan data semasa atau sejarah.

Hari vs nychthemeron, tempoh vs tempoh

Katakan bahawa sesuatu akan bertahan satu hari nanti. Jadi, jika ia bermula pada 09:15:00 PG maka kita boleh menambah 24 jam dan untuk mendapatkan masa tamat (09:15:00 PG hari berikutnya secara eksklusif, dalam kes ini).

Nah, ia tidak selalunya begitu mudah! Perlu diingat bahawa kita boleh mempunyai peralihan DST apabila jam dilaraskan secara buatan ke hadapan atau ke belakang. Ini bermakna hari biasanya berlangsung 24 jam tetapi, kadang-kadang, ia mungkin 23, 25 atau nilai yang lebih pelik seperti 27 atau 23 setengah jam (adakah anda ingat Casey dan Lord Howe?).

Adalah penting untuk tidak menganggap hari secara membuta tuli sebagai 24 jam apabila melaksanakan logik perniagaan. Anda harus menggunakan API tarikh/masa yang sesuai untuk itu. Sebagai contoh, dalam Java, kami mempunyai kelas yang berbeza:

• Tempoh, yang mewakili hari kalendar — sesuai untuk perkara seperti kesahan langganan yang diukur dalam hari, bulan atau tahun

• Tempoh, yang mewakili masa berterusan cth. 24 jam, tidak kira apa tarikh dalam kalendar. Ia sesuai untuk mengukur tempoh tindakan, seperti perjalanan atau masa sejak peranti/program bermula.

Sesetengah bahasa mempunyai perkataan yang berbeza untuk keadaan cahaya matahari (dalam bahasa Inggeris — hari) dan 24 jam berturut-turut (dalam bahasa Inggeris — nychthemeron, tetapi ia tidak biasa digunakan).

Perwakilan tarikh/masa:

Sumber: xkcd.com

Apabila berkomunikasi dengan sistem lain, seperti melalui REST API, adalah penting untuk bersetuju tentang format data. Jika anda melihat tarikh dipaparkan pada 10/12/2021, ia mungkin dalam format AS (12 Oktober) atau format UK (10 Disember).

Adalah lebih baik untuk menggunakan beberapa perwakilan yang tidak jelas!

Untuk tarikh dan masa, kami mempunyai standard ISO 8601. Ambil perhatian bahawa bukan sahaja tarikh/masa mutlak diseragamkan, tetapi juga tempoh. Ia juga penting untuk menggunakan jenis yang betul — setempat (untuk mewakili data seperti jam penggera yang mencetuskan masa atau tarikh lahir) atau dizonkan (untuk mewakili detik dalam masa, seperti acara bermula atau mengambil gambar).

Format tersuai dan tidak standard biasanya membawa kepada kekeliruan dan pepijat, jadi elakkannya.

Apabila memaparkan tarikh dan masa dalam UI, anda perlu mengambil kira tempat tempat pengguna. Format yang dipaparkan bergantung pada bahasa dan wilayah. Lihat contoh berikut yang semuanya merujuk pada tarikh yang sama:

• 18/4/21 — Bahasa Inggeris AS

• 18/04/2021 — Inggeris UK

• 18.04.2021 — Bahasa Romania

• ١٨‏/٤‏/٢٠٢١ — Arab Saudi, Arab dengan angka Arab Timur

Terdapat jenis format pratakrif yang disediakan mengikut pustaka tarikh/masa, seperti FormatStyle dalam java.time. Gunakan mereka jika boleh. Jika tidak, anda boleh membina lebih banyak format tersuai menggunakan simbol corak piawai. Lihat dokumentasi CLDR untuk butiran lanjut.

Perlu diingat bahawa, dalam kes bulan, suku dan hari dalam minggu, terdapat juga varian kendiri. Ia hanya bermakna dalam beberapa bahasa (bukan dalam bahasa Inggeris). Dalam bahasa Poland, sebagai contoh, April dipanggil kwiecień — ini ialah versi kendiri. Walau bagaimanapun, jika ia disambungkan dengan hari (cth. 18 April) teks menjadi 18 kwietnia.

Bungkus

Berurusan dengan tarikh dan masa bukanlah mudah. Walau bagaimanapun, jika anda mengikut piawaian yang diterangkan di atas dan menggunakan jenis yang betul, anda boleh mengelakkan kesilapan besar.

Saya harap pandangan saya tentang tarikh dan kes tepi masa akan berguna dalam projek anda. Semoga berjaya!

Diterbitkan pada asalnya di https://www.thedroidsonroids.com pada 26 April 2021.

Atas ialah kandungan terperinci Kes Edge dalam Pembangunan Apl dan Bahagian Belakang — Tarikh & Masa. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!