Pertanyaan Praktik terbaik waktu musim panas dan zona waktu [ditutup]


Saya berharap untuk membuat pertanyaan ini dan jawaban untuk itu panduan definitif untuk berurusan dengan waktu musim panas, khususnya untuk menangani perubahan overs yang sebenarnya.

Jika Anda memiliki sesuatu untuk ditambahkan, silakan lakukan

Banyak sistem bergantung pada menjaga waktu akurat, masalahnya adalah dengan perubahan waktu karena penghematan siang hari - menggerakkan jam maju atau mundur.

Misalnya, seseorang memiliki aturan bisnis dalam sistem pengambilan pesanan yang bergantung pada waktu pesanan - jika jam berubah, aturannya mungkin tidak jelas. Bagaimana seharusnya waktu dari perintah itu bertahan? Tentu saja ada banyak sekali skenario - yang satu ini hanyalah ilustrasi.

  • Bagaimana Anda menangani masalah daylight saving?
  • Asumsi apa yang menjadi bagian dari solusi Anda? (mencari konteks di sini)

Sama pentingnya, jika tidak lebih:

  • Apa yang Anda coba yang tidak berhasil?
  • Mengapa itu tidak berhasil?

Saya akan tertarik dalam pemrograman, OS, ketekunan data dan aspek-aspek terkait lainnya dari masalah ini.

Jawaban umum bagus, tetapi saya juga ingin melihat detail terutama jika mereka hanya tersedia di satu platform.


1885


asal


Jawaban:



Ringkasan jawaban dan data lainnya: (silakan tambahkan milik Anda)

Melakukan:

  • Kapan pun Anda mengacu pada waktu yang tepat, pertahankan waktu sesuai dengan standar terpadu yang tidak terpengaruh oleh daylight savings. (GMT dan UTC setara dengan hal ini, tetapi lebih disukai menggunakan istilah UTC. Perhatikan bahwa UTC juga dikenal sebagai UTC Zulu atau Z waktu.)
  • Jika sebaliknya Anda memilih untuk mempertahankan waktu menggunakan nilai waktu lokal, sertakan offset waktu lokal untuk waktu tertentu dari UTC (penggantian ini dapat berubah sepanjang tahun), sehingga stempel waktu dapat diinterpretasikan secara tidak ambigu.
  • Dalam beberapa kasus, Anda mungkin perlu menyimpan kedua waktu UTC dan waktu lokal yang setara. Seringkali ini dilakukan dengan dua bidang terpisah, tetapi beberapa platform mendukung datetimeoffset jenis yang dapat menyimpan keduanya dalam satu bidang.
  • Saat menyimpan stempel waktu sebagai nilai numerik, gunakan Waktu Unix - yang merupakan jumlah detik seluruh sejak 1970-01-01T00:00:00Z (tidak termasuk detik kabisat). Jika Anda membutuhkan presisi yang lebih tinggi, gunakan milidetik sebagai gantinya. Nilai ini harus selalu didasarkan pada UTC, tanpa penyesuaian zona waktu.
  • Jika nanti Anda mungkin perlu mengubah stempel waktu, sertakan ID zona waktu asli sehingga Anda dapat menentukan apakah offset mungkin telah berubah dari nilai asli yang tercatat.
  • Saat menjadwalkan acara di masa depan, biasanya waktu lokal lebih disukai daripada UTC, karena biasanya perubahan offset berubah. Lihat jawaban, dan posting blog.
  • Saat menyimpan seluruh tanggal, seperti ulang tahun dan hari jadi, jangan mengonversi ke UTC atau zona waktu lainnya.
    • Jika memungkinkan, simpan dalam jenis data tanggal-saja yang tidak termasuk waktu dalam sehari.
    • Jika tipe seperti itu tidak tersedia, pastikan untuk selalu mengabaikan waktu saat menafsirkan nilai. Jika Anda tidak dapat diyakinkan bahwa waktu siang hari akan diabaikan, pilih 12:00 siang, daripada 00:00 Tengah malam sebagai waktu representatif yang lebih aman pada hari itu.
  • Ingat bahwa offset zona waktu tidak selalu merupakan jumlah jam integer (misalnya, Waktu Standar India adalah UTC + 05: 30, dan Nepal menggunakan UTC + 05: 45).
  • Jika menggunakan Java, gunakan java.time untuk Java 8, atau gunakan Joda Time untuk Java 7 atau lebih rendah.
  • Jika menggunakan .BERSIH, pertimbangkan untuk menggunakan Noda Time.
  • Jika menggunakan .NET tanpa Noda Time, pertimbangkan itu DateTimeOffset seringkali merupakan pilihan yang lebih baik daripada DateTime.
  • Jika menggunakan Perl, gunakan Tanggal Waktu.
  • Jika menggunakan Python, gunakan pytz atau dateutil.
  • Jika menggunakan JavaScript, gunakan moment.js dengan zona waktu-saat perpanjangan.
  • Jika menggunakan PHP> 5.2, gunakan konversi zona waktu bawaan yang disediakan oleh DateTime, dan DateTimeZone kelas. Hati-hati saat menggunakan DateTimeZone::listAbbreviations() - Lihat jawaban. Untuk menjaga PHP dengan data Olson terbaru, instal secara berkala timezonedb Paket PECL; Lihat jawaban.
  • Jika menggunakan C ++, pastikan untuk menggunakan pustaka yang menggunakan aplikasi yang benar Database zona waktu IANA. Ini termasuk cctz, ICU, dan Perpustakaan "tz" milik Howard Hinnant.
    • Jangan gunakan Dorongan untuk konversi zona waktu. Sementara API-nya klaim untuk mendukung standar IANA (alias "zoneinfo") pengenal, itu dengan kasar memetakan mereka ke data gaya POSIX, tanpa mempertimbangkan sejarah perubahan yang kaya yang mungkin dimiliki setiap zona. (Juga, file telah jatuh dari pemeliharaan.)
  • Sebagian besar aturan bisnis menggunakan waktu sipil, bukan UTC atau GMT. Oleh karena itu, rencanakan untuk mengonversi stempel waktu UTC ke zona waktu lokal sebelum menerapkan logika aplikasi.
  • Ingat bahwa zona waktu dan offset tidak diperbaiki dan dapat berubah. Misalnya, secara historis AS dan Inggris menggunakan tanggal yang sama untuk 'pegas maju' dan 'mundur'. Namun, pada tahun 2007 AS mengubah tanggal bahwa jam dapat diubah. Ini sekarang berarti bahwa selama 48 minggu tahun perbedaan antara waktu London dan waktu New York adalah 5 jam dan selama 4 minggu (3 di musim semi, 1 di musim gugur) itu adalah 4 jam. Waspadai hal-hal seperti ini dalam perhitungan apa pun yang melibatkan beberapa zona.
  • Pertimbangkan jenis waktu (waktu kejadian aktual, waktu siaran, waktu relatif, waktu historis, waktu berulang) elemen apa (cap waktu, offset zona waktu dan nama zona waktu) yang perlu Anda simpan untuk pengambilan yang benar - lihat "Jenis Waktu" di jawaban ini.
  • Jaga OS Anda, basis data, dan file tzdata aplikasi sinkron, di antara mereka dan seluruh dunia.
  • Pada server, atur jam hardware dan jam OS ke UTC daripada zona waktu lokal.
  • Terlepas dari titik peluru sebelumnya, kode sisi server, termasuk situs web, seharusnya tak pernah mengharapkan zona waktu lokal dari server menjadi sesuatu yang khusus. Lihat jawaban.
  • Lebih suka bekerja dengan zona waktu berdasarkan kasus per kasus dalam kode aplikasi Anda, daripada secara global melalui pengaturan file konfigurasi atau default.
  • Menggunakan NTP layanan di semua server.
  • Jika menggunakan FAT32, ingat bahwa stempel waktu disimpan dalam waktu lokal, bukan UTC.
  • Ketika berhadapan dengan acara rutin (acara TV mingguan, misalnya), ingatlah bahwa waktu berubah dengan DST dan akan berbeda di seluruh zona waktu.
  • Selalu kueri nilai waktu-tanggal sebagai termasuk dalam batas bawah, eksklusif batas atas (>=, <).

Jangan:

  • Jangan bingung "zona waktu", seperti America/New_York dengan "zona waktu offset", seperti -05:00. Mereka adalah dua hal yang berbeda. Lihat wiki tag zona waktu.
  • Jangan gunakan JavaScript Date objek untuk melakukan perhitungan tanggal dan waktu di browser web yang lebih lama, seperti ECMAScript 5.1 dan yang lebih rendah cacat desain yang mungkin menggunakan daylight saving time secara salah. (Ini telah diperbaiki dalam ECMAScript 6/2015).
  • Jangan percaya jam klien. Mungkin sangat tidak benar.
  • Jangan menyuruh orang untuk "selalu menggunakan UTC di mana-mana". Saran yang tersebar luas ini adalah pandangan yang tidak jelas dari beberapa skenario valid yang dijelaskan sebelumnya dalam dokumen ini. Sebaliknya, gunakan referensi waktu yang tepat untuk data yang Anda kerjakan. (Timestamping dapat menggunakan UTC, tetapi penjadwalan waktu mendatang dan nilai tanggal saja tidak boleh.)

Pengujian:

  • Saat menguji, pastikan Anda menguji negara-negara di Barat, Timur, Utara, dan Selatan hemisfer (sebenarnya di setiap kuartal dunia, jadi 4 wilayah), dengan DST yang sedang berlangsung dan tidak (memberi 8), dan negara yang tidak menggunakan DST (4 lainnya untuk mencakup semua wilayah, membuat total 12).
  • Uji transisi DST, yaitu ketika Anda saat ini di waktu musim panas, pilih nilai waktu dari musim dingin.
  • Uji batas kasus, seperti zona waktu yang UTC + 12, dengan DST, membuat waktu lokal UTC + 13 di musim panas dan bahkan tempat-tempat yang UTC + 13 di musim dingin
  • Uji semua pustaka dan aplikasi pihak ketiga dan pastikan mereka menangani data zona waktu dengan benar.
  • Uji zona waktu setengah jam, setidaknya.

Referensi:

Lain:

  • Lobi perwakilan Anda untuk mengakhiri kekejian yang DST. Kami selalu bisa berharap ...
  • Lobi untuk Waktu Standar Bumi

802



Saya tidak yakin apa yang bisa saya tambahkan ke jawaban di atas, tetapi berikut beberapa poin dari saya:

Jenis waktu

Ada empat waktu berbeda yang harus Anda pertimbangkan:

  1. Waktu acara: misalnya, waktu ketika peristiwa olahraga internasional terjadi, atau penobatan / kematian / dll. Ini tergantung pada zona waktu acara dan bukan dari pemirsa.
  2. Waktu televisi: misalnya, acara TV tertentu disiarkan pada pukul 9 malam waktu setempat di seluruh dunia. Penting ketika berpikir tentang menerbitkan hasil (katakan American Idol) di situs web Anda
  3. Waktu relatif: misalnya: Pertanyaan ini memiliki penutupan hadiah terbuka dalam 21 jam. Ini mudah ditampilkan
  4. Waktu Berulang: misalnya: Acara TV diadakan setiap hari Senin jam 9 malam, bahkan ketika DST berubah.

Ada juga waktu Bersejarah / alternatif. Ini menjengkelkan karena mereka mungkin tidak memetakan kembali ke waktu standar. Misalnya: tanggal Julian, tanggal menurut kalender Bulan di Saturnus, kalender Klingon.

Menyimpan stempel waktu mulai / akhir di UTC berfungsi dengan baik. Untuk 1, Anda perlu nama zona waktu acara + offset disimpan bersama dengan acara. Untuk 2, Anda memerlukan pengidentifikasi waktu lokal yang disimpan dengan setiap wilayah dan nama zona waktu lokal + offset disimpan untuk setiap penampil (mungkin untuk memperoleh ini dari IP jika Anda berada dalam krisis). Untuk 3, simpan dalam UTC detik dan tidak perlu untuk zona waktu. 4 adalah kasus khusus 1 atau 2 tergantung pada apakah itu acara global atau lokal, tetapi Anda juga perlu menyimpan dibuat di cap waktu sehingga Anda dapat mengetahui apakah definisi zona waktu diubah sebelum atau setelah acara ini dibuat. Ini diperlukan jika Anda perlu menampilkan data historis.

Menyimpan kali

  • Selalu simpan waktu di UTC
  • Konversikan ke waktu lokal pada tampilan (lokal ditentukan oleh pengguna yang melihat data)
  • Saat menyimpan zona waktu, Anda membutuhkan nama, stempel waktu, dan offset. Ini diperlukan karena pemerintah kadang-kadang mengubah arti dari zona waktu mereka (misalnya: pemerintah AS mengubah tanggal DST), dan aplikasi Anda perlu menangani hal-hal dengan anggun ... misalnya: Stempel waktu yang tepat saat episode Hilang menunjukkan baik sebelum dan sesudah aturan DST berubah.

Offset dan nama

Contoh di atas adalah:

Pertandingan final piala dunia sepak bola   terjadi di Afrika Selatan (UTC + 2 - SAST)   pada 11 Juli 2010 pukul 19:00 UTC.

Dengan informasi ini, kita dapat secara historis menentukan waktu yang tepat ketika final WCS 2010 berlangsung bahkan jika definisi zona waktu Afrika Selatan berubah, dan dapat menampilkan itu kepada pemirsa di zona waktu lokal mereka pada saat mereka menanyakan basis data.

Waktu Sistem

Anda juga perlu menjaga OS Anda, database dan file tzdata aplikasi sinkron, baik dengan satu sama lain, dan dengan seluruh dunia, dan uji secara ekstensif ketika Anda meningkatkan. Tidak pernah terdengar bahwa aplikasi pihak ketiga yang Anda andalkan tidak menangani perubahan TZ dengan benar.

Pastikan jam perangkat keras diatur ke UTC, dan jika Anda menjalankan server di seluruh dunia, pastikan OS mereka dikonfigurasi untuk menggunakan UTC juga. Hal ini menjadi jelas ketika Anda perlu menyalin file log apache yang dirotasi setiap jam dari server dalam beberapa zona waktu. Menyortirnya dengan nama file hanya berfungsi jika semua file diberi nama dengan zona waktu yang sama. Ini juga berarti bahwa Anda tidak harus melakukan perhitungan tanggal di kepala Anda ketika Anda ssh dari satu kotak ke kotak lain dan perlu membandingkan cap waktu.

Juga, jalankan ntpd pada semua kotak.

Klien

Jangan percaya stempel waktu yang Anda dapatkan dari mesin klien sebagai valid. Misalnya, Tanggal: header HTTP, atau javascript Date.getTime() panggilan. Ini bagus ketika digunakan sebagai pengidentifikasi buram, atau ketika melakukan matematika tanggal selama satu sesi pada klien yang sama, tetapi jangan mencoba untuk referensi silang nilai-nilai ini dengan sesuatu yang Anda miliki di server. Klien Anda tidak menjalankan NTP, dan mungkin belum tentu memiliki baterai yang berfungsi untuk jam BIOS mereka.

Trivia

Akhirnya, pemerintah terkadang akan melakukan hal-hal yang sangat aneh:

Waktu standar di Belanda adalah   tepat 19 menit dan 32,13 detik   di depan UTC oleh hukum dari 1909-05-01   melalui 1937-06-30. Zona waktu ini   tidak dapat diwakili dengan tepat menggunakan   format HH: MM.

Ok, saya pikir saya sudah selesai.


288



Ini adalah masalah yang penting dan sangat sulit. Yang benar adalah bahwa tidak ada standar yang sepenuhnya memuaskan untuk bertahan waktu. Sebagai contoh, standar SQL dan format ISO (ISO 8601) jelas tidak cukup.

Dari sudut pandang konseptual, biasanya berurusan dengan dua jenis data waktu-tanggal, dan mudah untuk membedakan mereka (standar di atas tidak): "waktu fisik"dan"waktu sipil".

Waktu instan "fisik" adalah titik dalam garis waktu universal berkesinambungan yang dihadapi fisika (mengabaikan relativitas, tentu saja). Konsep ini dapat dikodekan secara memadai dalam UTC, misalnya (jika Anda dapat mengabaikan detik kabisat).

Waktu "sipil" adalah spesifikasi datetime yang mengikuti norma sipil: titik waktu di sini sepenuhnya ditentukan oleh sekumpulan bidang datetime (Y, M, D, H, MM, S, FS) ditambah TZ (spesifikasi zona waktu) (juga "kalender", sebenarnya; tetapi mari kita asumsikan kita membatasi diskusi ke kalender Gregorian). Sebuah zona waktu dan kalender secara bersama memungkinkan (secara prinsip) memetakan dari satu representasi ke representasi lainnya. Tetapi instants waktu sipil dan fisik pada dasarnya adalah jenis besaran yang berbeda, dan mereka harus tetap dipisahkan secara konseptual dan diperlakukan berbeda (analogi: array byte dan string karakter).

Masalahnya membingungkan karena kita berbicara tentang peristiwa jenis ini secara bergantian, dan karena waktu sipil tunduk pada perubahan politik. Masalahnya (dan kebutuhan untuk membedakan konsep-konsep ini) menjadi lebih jelas untuk kejadian di masa depan. Contoh (diambil dari diskusi saya sini.

John mencatat dalam kalendernya sebuah pengingat untuk suatu peristiwa pada saat itu 2019-Jul-27, 10:30:00, TZ =Chile/Santiago, (yang telah mengimbangi GMT-4, maka itu sesuai dengan UTC 2019-Jul-27 14:30:00). Tetapi suatu hari nanti di masa depan, negara memutuskan untuk mengubah TZ offset ke GMT-5.

Sekarang, ketika hari itu tiba ... haruskah pengingat itu memicu

SEBUAH) 2019-Jul-27 10:30:00 Chile/Santiago  = UTC time 2019-Jul-27 15:30:00 ?

atau

B) 2019-Jul-27 9:30:00 Chile/Santiago  = UTC time 2019-Jul-27 14:30:00 ?

Tidak ada jawaban yang benar, kecuali ada yang tahu apa yang secara konseptual dimaksudkan oleh Yohanes ketika dia memberi tahu kalender "Tolong telepon aku 2019-Jul-27, 10:30:00 TZ=Chile/Santiago".

Apakah maksudnya "tanggal waktu sipil" ("ketika jam di kota saya tahu 10:30 ")? Dalam hal ini, A) adalah jawaban yang benar.

Atau maksudnya "instan fisik waktu", titik dalam kontinum garis waktu alam semesta kita, katakan, "kapan gerhana matahari berikutnya terjadi ". Dalam hal itu, jawab B) adalah yang benar.

Beberapa API Tanggal / Waktu mendapatkan pembedaan ini dengan benar: di antaranya, Jodatime, yang merupakan dasar dari Java DateTime API berikutnya (ketiga!) (JSR 310).


81



Buatlah pemisahan arsitektural yang jelas dari kekhawatiran - untuk mengetahui dengan tepat tingkatan mana yang berinteraksi dengan pengguna, dan harus mengubah tanggal-waktu untuk / dari representasi kanonis (UTC). Waktu tanggal non-UTC adalah presentasi (ikuti zona waktu lokal pengguna), Waktu UTC adalah model (tetap unik untuk back-end dan mid tiers).

Juga, putuskan apa yang sebenarnya audiens Anda, apa yang Anda tidak harus melayani dan di mana Anda menarik garis. Jangan sentuh kalender eksotis kecuali Anda benar-benar memiliki pelanggan penting di sana dan kemudian mempertimbangkan server yang terpisah untuk pengguna (-pengguna) hanya untuk wilayah itu.

Jika Anda dapat memperoleh dan mempertahankan lokasi pengguna, gunakan lokasi untuk konversi tanggal-waktu yang sistematis (katakanlah. NET budaya atau tabel SQL) tetapi berikan cara bagi pengguna akhir untuk memilih menimpa jika tanggal-waktu sangat penting untuk pengguna Anda.

Jika ada kewajiban audit historis terlibat (seperti memberi tahu dengan tepat kapan Jo di AZ membayar tagihan 2 thn lalu di bulan September) kemudian simpan waktu UTC dan waktu lokal untuk catatan (tabel konversi Anda akan berubah seiring waktu).

Tentukan zona waktu referensi waktu untuk data yang datang dalam jumlah besar - seperti file, layanan web, dll. Say East Coast company memiliki pusat data di CA - Anda perlu bertanya dan tahu apa yang mereka gunakan sebagai standar daripada mengasumsikan satu atau yang lain.

Jangan percaya offset zona waktu yang tertanam dalam representasi tekstual dari tanggal dan waktu jangan menerima untuk mengurai dan mengikuti mereka. Sebaliknya, selalu minta zona waktu dan / atau zona referensi harus ditetapkan secara eksplisit. Anda dapat dengan mudah menerima waktu dengan PST offset tetapi waktu sebenarnya EST karena itu waktu referensi dan catatan klien hanya diekspor di server yang ada di PST.


53



Anda perlu tahu tentang Olson tz database, yang tersedia dari ftp://elsie.nci.nih.gov/pub  http://iana.org/time-zones/. Ini diperbarui beberapa kali per tahun untuk menangani perubahan menit-menit terakhir ketika (dan apakah) beralih antara musim dingin dan musim panas (standar dan waktu musim panas) di berbagai negara di seluruh dunia. Pada tahun 2009, rilis terakhir adalah 2009; pada 2010, 2010n; pada 2011, 2011n; pada akhir Mei 2012, rilisnya adalah 2012c. Perhatikan bahwa ada satu set kode untuk mengelola data dan data zona waktu aktual itu sendiri, dalam dua arsip terpisah (tzcode20xxy.tar.gz dan tzdata20xxy.tar.gz). Baik kode dan data berada di domain publik.

Ini adalah sumber nama zona waktu seperti Amerika / Los_Angeles (dan sinonim seperti AS / Pasifik).

Jika Anda perlu melacak zona yang berbeda, maka Anda memerlukan basis data Olson. Seperti yang telah disarankan orang lain, Anda juga ingin menyimpan data dalam format tetap - UTC biasanya yang dipilih - bersama dengan catatan zona waktu di mana data dihasilkan. Anda mungkin ingin membedakan antara offset dari UTC pada saat itu dan nama zona waktu; yang bisa membuat perbedaan nantinya. Selain itu, mengetahui bahwa saat ini 2010-03-28T23: 47: 00-07: 00 (AS / Pasifik) dapat atau tidak dapat membantu Anda dalam menafsirkan nilai 2010-11-15T12: 30 - yang mungkin ditentukan dalam PST ( Waktu Standar Pasifik) daripada PDT (Waktu Musim Panas Pasifik).

Antarmuka perpustakaan C standar tidak sangat membantu dengan hal-hal semacam ini.


Data Olson telah pindah, sebagian karena A D Olson akan segera pensiun, dan sebagian karena ada (sekarang diberhentikan) tuntutan hukum terhadap pengelola untuk pelanggaran hak cipta. Database zona waktu sekarang dikelola di bawah naungan IANA, Otoritas Nomor yang Ditetapkan Internet, dan ada tautan di halaman depan 'Database Zona Waktu'. Milis diskusi sekarang tz@iana.org; daftar pengumumannya tz-announce@iana.org.


38



Secara umum, sertakan offset waktu lokal (termasuk DST offset) dalam stempel waktu yang disimpan: UTC saja tidak cukup jika nanti Anda ingin menampilkan stempel waktu dalam zona waktu aslinya (dan pengaturan DST).

Perlu diingat bahwa offset tidak selalu merupakan jumlah jam integer (misalnya, Waktu Standar India adalah UTC + 05: 30).

Sebagai contoh, format yang sesuai adalah tuple (waktu unix, offset dalam menit) atau ISO 8601.


24



Melintasi batas "waktu komputer" dan "waktu orang" adalah mimpi buruk. Yang utama adalah bahwa tidak ada semacam standar untuk aturan yang mengatur zona waktu dan waktu musim panas. Negara-negara bebas untuk mengubah zona waktu dan aturan DST mereka kapan saja, dan mereka melakukannya.

Beberapa negara misalnya Israel, Brasil, memutuskan setiap tahun kapan waktu daylight saving mereka, sehingga tidak mungkin untuk mengetahui sebelumnya ketika (jika) DST akan berlaku. Yang lain telah menetapkan aturan (ish) kapan DST berlaku. Negara-negara lain tidak menggunakan DST karena semua.

Zona waktu tidak harus menjadi selisih jam penuh dari GMT. Nepal adalah +5,45. Bahkan ada zona waktu yang +13. Itu berarti bahwa:

SUN 23:00 in Howland Island (-12)
MON 11:00 GMT 
TUE 00:00 in Tonga (+13)

semua waktu yang sama, namun 3 hari yang berbeda!

Juga tidak ada standar yang jelas pada singkatan untuk zona waktu, dan bagaimana perubahannya ketika di DST sehingga Anda berakhir dengan hal-hal seperti ini:

AST Arab Standard Time     UTC+03
AST Arabian Standard Time  UTC+04
AST Arabic Standard Time   UTC+03

Saran terbaik adalah menjauh dari waktu setempat sebanyak mungkin dan tetaplah di UTC di mana Anda bisa. Konversi hanya ke waktu lokal pada saat-saat terakhir.

Saat pengujian, pastikan Anda menguji negara di belahan Barat dan Timur, dengan DST yang sedang berlangsung dan tidak serta negara yang tidak menggunakan DST (6 total).


22



Untuk PHP:

Kelas DateTimeZone di PHP> 5.2 sudah didasarkan pada Olson DB yang disebutkan orang lain, jadi jika Anda melakukan konversi zona waktu dalam PHP dan bukan di DB, Anda dibebaskan dari bekerja dengan (yang sulit dipahami) file Olson.

Namun, PHP tidak diperbarui sesering DB Olson, jadi hanya menggunakan konversi zona waktu PHPs dapat meninggalkan Anda dengan informasi DST yang kedaluwarsa, dan mempengaruhi kebenaran data Anda. Meskipun hal ini tidak diharapkan terjadi secara sering, itu mungkin terjadi, dan akan terjadi jika Anda memiliki basis pengguna yang besar di seluruh dunia.

Untuk mengatasi masalah di atas, gunakan paket pecl timezonedb, fungsi itu adalah untuk memperbarui data zona waktu PHP. Instal paket ini sesering yang diperbarui. (Saya tidak yakin apakah pembaruan paket ini mengikuti pembaruan Olson dengan tepat, tetapi tampaknya diperbarui dalam frekuensi yang setidaknya sangat dekat dengan pembaruan Olson.)


18



Jika desain Anda dapat mengakomodasi itu, hindari konversi waktu lokal bersama-sama! 

Saya tahu beberapa hal ini mungkin terdengar gila tetapi berpikir tentang UX: pengguna memproses dekat, tanggal relatif (hari ini, kemarin, Senin depan) lebih cepat dari tanggal absolut (2010.09.17, Jumat 17 September) sekilas. Dan ketika Anda memikirkannya lebih lanjut, keakuratan zona waktu (dan DST) lebih penting semakin dekat tanggalnya now(), jadi jika Anda dapat mengungkapkan tanggal / datetimes dalam format relatif untuk +/- 1 atau 2 minggu, sisa tanggal dapat menjadi UTC dan tidak akan terlalu penting bagi 95% pengguna.

Dengan cara ini Anda dapat menyimpan semua tanggal di UTC dan melakukan perbandingan relatif dalam UTC dan cukup menunjukkan tanggal UTC pengguna di luar Batas Tanggal Relatif Anda.

Ini juga dapat berlaku untuk input pengguna juga (tetapi umumnya dengan cara yang lebih terbatas). Memilih dari drop-down yang hanya memiliki {Yesterday, Today, Tomorrow, Next Monday, Next Thursday} jauh lebih sederhana dan lebih mudah bagi pengguna daripada pemilih tanggal. Pemilih tanggal adalah beberapa komponen yang menyebabkan rasa sakit yang paling banyak mengisi formulir. Tentu saja ini tidak akan berhasil untuk semua kasus tetapi Anda dapat melihat bahwa itu hanya membutuhkan sedikit desain pintar untuk membuatnya sangat kuat.


15



Meskipun saya belum mencobanya, pendekatan untuk penyesuaian zona waktu yang saya anggap menarik adalah sebagai berikut:

  1. Simpan semuanya dalam UTC.

  2. Buat tabel TZOffsets dengan tiga kolom: RegionClassId, StartDateTime, dan OffsetMinutes (int, dalam menit).

Di dalam tabel, simpan daftar tanggal dan waktu kapan waktu setempat berubah, dan seberapa banyak. Jumlah wilayah dalam tabel dan jumlah tanggal akan bergantung pada rentang tanggal dan wilayah dunia apa yang perlu Anda dukung. Anggaplah ini seolah-olah itu adalah tanggal "historis", meskipun tanggal-tanggal tersebut harus mencakup masa depan hingga batas praktis.

Ketika Anda perlu menghitung waktu lokal dari setiap waktu UTC, lakukan saja ini:

SELECT DATEADD('m', SUM(OffsetMinutes), @inputdatetime) AS LocalDateTime
FROM   TZOffsets
WHERE  StartDateTime <= @inputdatetime
       AND RegionClassId = @RegionClassId;

Anda mungkin ingin menyimpan tabel ini di aplikasi Anda dan menggunakan LINQ atau beberapa cara serupa untuk melakukan kueri daripada memukul database.

Data ini dapat disaring dari domain publik tz database.

Keuntungan dan catatan kaki dari pendekatan ini:

  1. Tidak ada aturan yang dipanggang ke dalam kode, Anda dapat menyesuaikan offset untuk wilayah baru atau rentang tanggal dengan mudah.
  2. Anda tidak perlu mendukung setiap rentang tanggal atau wilayah, Anda dapat menambahkannya sesuai kebutuhan.
  3. Wilayah tidak harus berhubungan langsung dengan batas geopolitik, dan untuk menghindari duplikasi baris (misalnya, sebagian besar negara bagian di AS menangani DST dengan cara yang sama), Anda dapat memiliki entri RegionClass yang luas yang tertaut di tabel lain ke daftar tradisional negara bagian, negara, dll.
  4. Untuk situasi seperti AS di mana tanggal mulai dan akhir DST telah berubah selama beberapa tahun terakhir, ini cukup mudah untuk ditangani.
  5. Karena bidang StartDateTime dapat menyimpan waktu juga, waktu perubahan standar 2:00 AM ditangani dengan mudah.
  6. Tidak semua tempat di dunia menggunakan DST 1 jam. Ini menangani kasus-kasus itu dengan mudah.
  7. Tabel data adalah cross-platform dan bisa menjadi proyek open-source terpisah yang dapat digunakan oleh pengembang yang menggunakan hampir semua platform database atau bahasa pemrograman.
  8. Ini dapat digunakan untuk offset yang tidak ada hubungannya dengan zona waktu. Misalnya, penyesuaian 1 detik yang terjadi dari waktu ke waktu untuk menyesuaikan rotasi Bumi, penyesuaian historis ke dan dalam kalender Gregorian, dll.
  9. Karena ini dalam tabel database, permintaan laporan standar, dll dapat mengambil keuntungan dari data tanpa perjalanan melalui kode logika bisnis.
  10. Ini juga menangani zona waktu offset jika Anda menginginkannya, dan bahkan dapat menjelaskan kasus-kasus historis khusus di mana suatu wilayah ditugaskan ke zona waktu lain. Yang Anda butuhkan hanyalah tanggal awal yang menetapkan zona waktu yang diimbangi ke setiap wilayah dengan tanggal mulai yang minimal. Ini akan membutuhkan pembuatan setidaknya satu wilayah untuk setiap zona waktu, tetapi akan memungkinkan Anda mengajukan pertanyaan-pertanyaan menarik seperti: "Apa perbedaan waktu setempat antara Yuma, Arizona dan Seattle, Washington pada tanggal 2 Februari 1989 pukul 5:00 pagi?" (Hanya kurangi satu SUM () dari yang lain).

Sekarang, satu-satunya kelemahan dari pendekatan ini atau lainnya adalah konversi itu dari waktu lokal ke GMT tidak sempurna, karena perubahan DST yang memiliki offset negatif ke jam mengulangi waktu lokal yang diberikan. Tidak ada cara mudah untuk berurusan dengan yang satu itu, saya khawatir, yang merupakan salah satu alasan menyimpan waktu lokal adalah berita buruk di tempat pertama.


15