Saran untuk store didatabase always store as UTC, untuk di level API contract bisa pake timestamp rfc 3339 itu udah ada standardnya. enaknya bisa flexible nanti client nya mau dlm bentuk timezone apa aja, terus dri sisi human lebih readable, dan itu udah ada spec conventionnya juga. Karena kekurangannya unix milis time kalau dibawah 1970 datanya jadi ga valid
nyimpen timestamp pakai unixtime itu considered as a bad practice, karena program perlu konversi unixtime nya dulu sebelum di consume sama client app, kalau ga mau ribet dengan multiple timezone pakai aja data type di database yang `datetime with timezone` dan setiap entry ke database make sure selalu sertakan timezone, selain itu ada masalah mengerikan lainnya kalau pakai unix time di kolom table yg tipenya 32 bit integer itu cuma bisa nyimpen sampai tahun 2038, bisa aja pakai bigint, tapi nanti kalau mau query time range akan jadi masalah lain dan jadinya ya nambah masalah
Biasanya saya pake format UTC, atau pake format ISO Date, atau bisa pake epoch miliseconds. Nanti di sisi klien tinggal dikonversi saja format date tersebut sesuai dengan waktu yang ada di klien nya
Menurut saya, kekurangan dari epoch/unix time ini kurang human readable secara sekilas. Dalam pekerjaan, saya sering kali hit API berbagai service dan query ke database untuk kebutuhan debugging, kalau misal data time berupa epoch jadi perlu waktu tambahan karena harus konversi nilai tersebut ke waktu yang sebenarnya. Begitu juga sebaliknya jika perlu untuk construct payload sebuah API, perlu mengubah waktu real menjadi format epoch. Terkait masalah ini, kadang di beberapa service ada yang menampilkan 2 data untuk time sebagai responsenya, epoch yang bentuk number (digunakan untuk kalkulasi) dan formatted time (digunakan untuk kebutuhan menampilkan waktu dalam format yang lebih human readable) Kalau saya untuk sekarang masih lebih memilih menyimpan data time di database dengan format timestamp with timezone, dan memastikan kalau kita query ke database menggunakan package yang support time with timezone. Sedangkan untuk komunikasi data, kalau bisa support keduanya: menggunakan string based yang juga memuat data timezone seperti `2022-05-11T08:00:00Z` dan juga format epoch. Karena memang kalau di URL query param, lebih convenient menggunakan format epoch.
semuanya ada problem (date, timestamp, unix time). ex, client papua insert jam 2 tanggal 1, terus client nampilin dari kalimantan jam 1:10 tanggal 2. kalau sekedar pakai unix time lalu disesuaikan time zone system. client bakal binggung, taunya dia daftar ini tanggal jam 2 di insert, kok malah jadi jam 1:10. begitupun kalau cuman date atau timestamp convertan dari timezone client. yang benar itu insert baik timezone server dan timezone client barengan disertai data pendukung seperti ipaddress. format selera date, timestamp, unix time.
@@davidstephen7070 sorry bang saya kurang paham dengan example diatas 🙏 semisal : - user A dari papua dengan localtime WIT insert data jam 02-00 WIT - user B dari jawa dengan localtime WIB melihat data dari user A, maka akan terlihat bahwa user A insert data jam 00-00 WIB kalau misal user masih bingung, bisa coba dikaji lewat UI/UX apakah perlu menampilkan suffix timezone seperti WIT/WIB untuk waktu menurut saya, data time yang disimpan di database itu cukup format "timestamp with timezone" atau format epoch. Tidak perlu data timezone server, timezone client, apalagi ip adsress, karena: - server itu technically bisa berada di multiple datacenter/timezone - client juga dapat mengakses server dari berbagai lokasi/timezone - ip address juga selalu berubah tergantung koneksi & lokasi user dari video mas eko di atas juga dijelaskan yang berbahaya adalah : menyimpan data time (tanggal & jam) tanpa menyimpan timezone nya, sehingga dari sisi app level harus tahu data time yang diterima dari database tersebut berada di timezone mana. cmiiw
@@andregandawida pakai suffix WIT/WIB juga bisa. itu berlaku untuk data realtime. untuk data yang membutuhkan integritas di kemudian hari wajib berdasarkan darimana asal data tersebut dimasukkan. contoh, data skripsi virus insert dari papua tanggal 24 maret 2999 23:00:00. kemudian, pembuat skripsi membacanya kembali di 5 Mei 3015. kalau sekedar convertan timezone dari client. saat client pindah timezone akan hilang integritasnya.
Saya juga pakai approach yg sama. Sebenarnya yg penting adalah ketika menyimpan harus menggunakan timezone yg sama. Epoch pun saya pernah dapet pengalaman pait karena Swift (iOS) itu format Epoch nggak sampe miliseconds, harus dikali 1000 dulu. Itu pusing sampai 2 bulan iOS dev nya buat Debugging. Belum lagi kalau dr Client kirimnya milis gt ada kemungkinan salah konversi, yg di konversi ke milis timezone nya jg beda dr server. Bakal Civil War antar Developer 😅
Thank you kang Eko, superb membantu nih. Biasanya kita simpan date as string biar bisa simpan sampai timezone. Pakai epoch lebih mantap, untuk prevent format waktu yang gak kita inginkan dari FE.
Pada embeded system, penggunaan epoch time adalah hal wajib. Anda tidak akan tahu perangkat berada di zona waktu mana. Embeded menggunakan epoch second uint64 (64bit), karena epoch milis boros memory. Sekitaran 2000 an (jaman 32 bit) epoch second yang digunakan adalah int32 sehingga akan roll-over pada (03:14:07 UTC 19 January 2038 ) [Epochalypse the Friday 13th Bug], hal ini bisa ditemukan di perangkat-perangkat GPS tracker (offline). Oh ya, ada hal yang terlewat. penggunaan epoch time (second/milis) menggindarkan dari masalah zona waktu yang menggunakan Daylight Saving Time (DST) (Summer time). Waktu lokal dapat maju/mundur tergantung pada tanggal dan zona waktu.
masih kang eko, saya lagi ngerasain kasusnya wkwkwkwkwk emang ribet parah kadang2 error pas manggil API kalo pake tide data `DateTime` biasa, makasih banyak kang
Kalau pengalaman saya di erp odoo, kalau ngak salah saya lihat didatabase mereka, itu disimpan dalam utc. Jadi setiap client itu dikasih opsi konfigurasi timezone di akun mereka. lalu ada orm juga untuk nangani masalah date ini kalau ngak salah. jadi kalau query pakai orm bakal di ubah ke timezone utc. cuman permasalahannya kalau querynya complex dan harus raw query, atau kalau buat proses output berupa print sih.
Saya dulu pernah bikin aplikasi pakai api telegram, mereka juga pakai unix timestamp seperti itu untuk tanggal dan jam pesannya. Di sisi aplikasi saya, tinggal konversi ke tanggal lokal untuk tampilannya
menurut saya masih lebih simple cara yang disimpan pake date bg yg formatnya timestamp atau ISO date dan datanya lebih mudah dibaca kalau untuk debugging, timestamp di database best practice nya harus disimpan dalam timezone UTC+0 , dan nanti kalau ada request dari client yg timezonenya beda2 tinggal di convert aja jadi UTC lalu save di database ...
4:01 Haha.. Acak Kadut. ------------------------ Di beberapa pengalaman coding Integrasi dengan EDC Terminal (pake .NET dan C#). Kebanyakan requirement SDK dari Vendornya memang pakai Unix Epoch Time Mantap penjelasannya.
sangat bermanfaat kang dari sisi programmer, saya juga pernah kena masalah di zona waktu... mau tanya juga kang, kalau simpan data waktu di DB atau dari sisi API balikin data waktu by unixTime, dari sisi QA (bukan QA engineer) untuk checking datanya nya gimana ya kang? kaya yang tadi createdDate, TransactionDate dll, kayaknya dari sisi mereka yang jadinya agak ribet. soalnya di tempat saya bekerja, QA itu sering check Data by DB atau Json.... atau teman2 yg lain mau sharing bleh banget nihh.. thanks
Saya lebih memilih pakai ISO-8601. Postgres juga bisa menerima ISO-8601. Banyak bahasa pemrograman juga sudah mendukung ISO-8601. Keuntungan dari ISO-8601 adalah: bisa dibaca oleh manusia, dan kita juga bisa pertahankan TZ yang dianjurkan klien/server. Untuk presentasi, sepakat kita bisa simpan saja preferensi TZ client, untuk kemudian client bisa melakukan konversi timestampnya ke TZ yang mereka butuhkan.
Enaknya pakai Epoch, kalau app kita untuk visualisasi data bisa melihat berdasarkan 30 hari terakhir, 15 hari terakhir, dll. Hanya saja tidak human-friendly menurut saya
Kalau saya lebih suka pakai ISO format karena lebih mudah dibaca dan tetap standar. Contoh penulisan ISO adalah 2022-08-12T02:58:04Z. Tapi kalau terpaksa banget harus menyimpan timezone tinggal kita tambahkan saja di belakang contohnya 2022-08-12T02:58:04+07:00
mas, kalau ini tipe datanya di database apa ya? tetap pake varchar atau timestamptz? soalnya, kalau saya pake timestamptz, timezonenya tetap ngikut server.
Baru ketemu reason nya kenapa kalau get api2 produk luar selalu unix epoch tuntuk field2 yg menunjukan waktu Baru2 ini soalnya lagi sering2 ngulik api spotify
kalau handle data multi timezone sekedar pakai epoch timezone dari client bakal ada bug, bagusnya itu saat insert ada 2 data, timezone server dan timezone client, ketika data client pada saat insert dan ditampilkan di waktu berbeda. ex, server di jakarta, client di papua. data dimasukkan dari timezone papua, lalu client pergi ke kalimantan timezonenya beda lagi. sebaiknya data yang ditampilkan berdasarkan beberapa data tambahan lain seperti, ip client, user agent browser, dan data2 lain. fungsi untuk verifikasi client komplain kedepannya, jika client insert data dari papua, tapi komplain dari kalimantan. dicatatan client taunya jam 2 saat di papua, di kalimantan jam 1 saat ini. epoch unix gak tau hal beginian, disini terjadi masalahnya. mau pakai date, timestamp, epoch unix. tetap akan mengalami hal beginian, jadi harus diketahui data apa yang ditampilkan, jadi bisa diambil keputusan mau data waktu disesuaikan timezone system pengguna, atau sesuai darimana timezone tersebut dimasukkan.
ga perlu , timezone di hp/laptop itu udah otomatis detect lokasi, kecuali dia ga aktifin timezone otomatis nya. klo client komplain suruh cek tanggal/jam di devicenya sesuai ngga
@@danielalexander4265 kayaknya u gak paham yang gua maksud. benar, hp otomatis detek timezone. u simak yang kujelasin. lo sekarang ada di papua, timezone papua. insert data ke server jakarta timezone barat. selisih 2 jam. terus kau pindah ke kalimantan selisih 1 jam dari server. kalau cuman sekedar ngikutin timezone client, pas kau insert aja timestamp ditambahin 2 jam. pas client ke kalimantan. server tetap mengirim timestamp ditambah 2 jam. tapi sama timezone system client di kurangi 1 jam. disini letak permasalahannya. sedangkan, saat dikalimantan client taunya dia insert data pas dipapua jam 2. bukan jam 1. belum lagi kalau bicara akurasi ke menit. sebaiknya, insertkan data waktu keterangan timezone server dan timezone client.
@@davidstephen7070 engga gitu konsep multiple timezone mah misal di papua insert jam 2 Liat dikalimantan munculnya ya pasti jam 1 (yang dipapua insert datanya pada jam 1 waktu kalimantan) Klo malah munculnya jam 2 malah jadi problem lagi, misal sekarang dikalimantan masih jam 1:30 kok timestamp datanya jam 2 Klo misal mau kaya diatas artinya emang perlu modifikasi opsional nambahin timezone client pas insert, bukan bug di epoch nya 😃
@@danielalexander4265 maksud gua bug itu bukan epochnya tapi managemen sistem bakal nimbulin masalah. u gak paham yang sedang dibicarakan. misalnya, ini lo buat skripsi tentang politik lo insert nih dari papua selisih 2 jam. setelah berjalan 3 bulan, lo dikalimantan, lo list semua skripsi lo dari database, termasuk skripsi politik itu. kira2 lo nampilin waktu pembuatan skripsi sesuai timezone dimana sekarang timezone client? kalau lo sekedar gitu, buyar itu intergritas datanya. makanya, gak cukup sekedar pakai 1 timezone server hasil convertan dari timezone client. harus insert barengan keduanya. lebih bagus lagi ada tambahan data lain dari client berupa ip address.
@@davidstephen7070 ya balik lagi tergantung requirement apps nya, klo tanpa detail data lain bukan berarti jadi bug. Misal whatsapp, shopee, dll dia cuma simpen epoch doang pun ga ada masalah
mas Eko , mau nanyak... mas nya bisa se-expert sekarang dan bisa belajar banyak tentang teknologi dan bahasa pemrograman itu , mas nya belajar + baca dokumentasi + praktekan langsung apa modal cuma sering2 baca dokumentasi atau hal lain doang .
Belum pernah merhatiin penggunaan date, Tapi tanpa sadar rupanya udah sering implementasi di PHP, walaupun jadinya terkadang angkanya gak manusiawi (human readable), hahahaha
Agak sedikit membingungkan untuk pemula yang belum pernah mengimplementasikannya, mungkin kang eko boleh buat tutorial dari bahasa yg populer seperti php atau js?
Intinya sih konversi ke format tanggalnya kayak yyyy/mm/dd itu di client / frontend bukan dari backend, backend cuman ngasih epoch format aja karna itu value yang sifatnya universal.
Halo mau tanya, kalo pake kaya di video, misal saya ke sebuah web, melakukan transaksi di GMT +7 (jakarta), di save transaksinya pake epoch. kalau saya pindah timezone, berarti ketika saya buka history transaksi, itu createdAt nya berubah sesuai lokasi user dong? jadi berubah" kalo kita pindah tempat?
jangan pakai epoch, tapi, fix date sesuai multizone client dan server. kalau pakai epoch masalahnya seperti yang u jelasin. ditable harus ada informasi kapan data tersebut diinsert ke server, dan data waktu dari client, terus disertai informasi lain untuk menguatkan asal data tersebut seperti ip_address. jika, data tersebut penting. seperti, pembuatan skripsi dari papua.
unix timestamp? bukannya timestamp hanya menampung data hinggan januari 2038?. Berarti, jika saya simpan ke dalam tipedata BIGINT. Apa bisa bertahan hingga lebih dari 2038?
Biasanya disetor di databasenya make tipe data integer ya, bang? Saya barusan nyari, yang 4 byte bisa kena Year 2038 problem, berarti lgsg make yg 8 byte?
meski pakai UTC, akan tetap jadi masalah ketika backend masih pakai frame GMT tertentu (misal GMT+7), akhirnya terpaksa harus konversi dari GMT berbeda ke GMT yang dipakai backend :D. Sempat punya masalah dengan backend seperti ini, akhirya ya harus main konversi2 gitu di frontendnya
berarti kita tidak bisa langsung lihat data date time di database nya ya? kalau mau nge query manual di database buat ngeliat data date time, mesti di copy dulu ke excel atau platform lainnya buat nge convert unix epoch nya
Tips2 gini yang sangat ditunggu2. Simple tapi bakal kepake banget dikerjaan. Semoga kedepan banyak lagi konten tips2 dev kya gini. Thanks pak Eko!
Saran untuk store didatabase always store as UTC, untuk di level API contract bisa pake timestamp rfc 3339 itu udah ada standardnya. enaknya bisa flexible nanti client nya mau dlm bentuk timezone apa aja, terus dri sisi human lebih readable, dan itu udah ada spec conventionnya juga. Karena kekurangannya unix milis time kalau dibawah 1970 datanya jadi ga valid
betul.... tapi handling kebutuhan reporting misal.... mau cari data tanggal sekial sampe sekian... kl di kita kan pasti dimintanya yang +7?
@@ricardosawir responsibilitynya bisa di reporting downloader / workernya aja buat yg buat reportingnya jadi bentuk tertentu
@@mtsalis31jadi dilakukan di luar sql gitu ya?
emang ada y data yg tanggalnya dibawah 1970 😅
Paling seneng kalo kontennya kaya gini bisa didengerin pas lagi berangkat kerja, kira-kira upload dispotify juga gak kang didengerin enak soalnya
nyimpen timestamp pakai unixtime itu considered as a bad practice, karena program perlu konversi unixtime nya dulu sebelum di consume sama client app, kalau ga mau ribet dengan multiple timezone pakai aja data type di database yang `datetime with timezone` dan setiap entry ke database make sure selalu sertakan timezone, selain itu ada masalah mengerikan lainnya kalau pakai unix time di kolom table yg tipenya 32 bit integer itu cuma bisa nyimpen sampai tahun 2038, bisa aja pakai bigint, tapi nanti kalau mau query time range akan jadi masalah lain dan jadinya ya nambah masalah
kalo aku itu yg di sampekan mas eko udah best practice bgt, dan aku merasakebantu bgt
setelah cek2 mas gugle, pakai bigint di db buat nyimpen tanggal milisecond itu ngeri2 sedap. takut dimarahin orang warehouse.
untuk postgresql saran saya selalu menggunakan TIMESTAMPTZ default timezonenya GMT. saat read query convert mnggunakan AT TIME ZONE
Biasanya saya pake format UTC, atau pake format ISO Date, atau bisa pake epoch miliseconds. Nanti di sisi klien tinggal dikonversi saja format date tersebut sesuai dengan waktu yang ada di klien nya
Kalo misal disimpan pakai standar ISO,disimpennya pakai tipe data apa gan?
@@rzq8896 ya iso date bentuk String juga bisa pak.
@@RianY2K untuk sortasi data berdasarkan waktu,jadinya gmn ya kalo gak pakai tipe data date? Semisal mau ambil data 5 thn kebelakang?
Kalo di kantor saya pake GMT+0 om, jadi setiap ditampilkan ke user, akan ditambah kan sebanyak Timezone usernya
Saya mau bertanya, bagaimana Cara dapatkan data timezone usernya ?
@@antowijaya3678 biasanay disimpen timezone usernya, cara ini juga ga efektif, mending kata pak eko pakai unix epoch
Bearti server nya kan ya yg harus gmt+0 ?
@@aidenrhama9147 betul
@@antowijaya3678 di browser ada timezone user
Sangat suka tips dan informasi yg bro agan berikan. Terima kasih, semoga smakin barokah channel ini.
Wah pas bgt nonton ini. Kebetulan di kerjaan jd ada task terkait timezone. Thank you banget mas Eko
Menurut saya, kekurangan dari epoch/unix time ini kurang human readable secara sekilas.
Dalam pekerjaan, saya sering kali hit API berbagai service dan query ke database untuk kebutuhan debugging, kalau misal data time berupa epoch jadi perlu waktu tambahan karena harus konversi nilai tersebut ke waktu yang sebenarnya. Begitu juga sebaliknya jika perlu untuk construct payload sebuah API, perlu mengubah waktu real menjadi format epoch. Terkait masalah ini, kadang di beberapa service ada yang menampilkan 2 data untuk time sebagai responsenya, epoch yang bentuk number (digunakan untuk kalkulasi) dan formatted time (digunakan untuk kebutuhan menampilkan waktu dalam format yang lebih human readable)
Kalau saya untuk sekarang masih lebih memilih menyimpan data time di database dengan format timestamp with timezone, dan memastikan kalau kita query ke database menggunakan package yang support time with timezone. Sedangkan untuk komunikasi data, kalau bisa support keduanya: menggunakan string based yang juga memuat data timezone seperti `2022-05-11T08:00:00Z` dan juga format epoch. Karena memang kalau di URL query param, lebih convenient menggunakan format epoch.
semuanya ada problem (date, timestamp, unix time). ex, client papua insert jam 2 tanggal 1, terus client nampilin dari kalimantan jam 1:10 tanggal 2. kalau sekedar pakai unix time lalu disesuaikan time zone system. client bakal binggung, taunya dia daftar ini tanggal jam 2 di insert, kok malah jadi jam 1:10. begitupun kalau cuman date atau timestamp convertan dari timezone client. yang benar itu insert baik timezone server dan timezone client barengan disertai data pendukung seperti ipaddress. format selera date, timestamp, unix time.
@@davidstephen7070 sorry bang saya kurang paham dengan example diatas 🙏
semisal :
- user A dari papua dengan localtime WIT insert data jam 02-00 WIT
- user B dari jawa dengan localtime WIB melihat data dari user A, maka akan terlihat bahwa user A insert data jam 00-00 WIB
kalau misal user masih bingung, bisa coba dikaji lewat UI/UX apakah perlu menampilkan suffix timezone seperti WIT/WIB untuk waktu
menurut saya, data time yang disimpan di database itu cukup format "timestamp with timezone" atau format epoch. Tidak perlu data timezone server, timezone client, apalagi ip adsress, karena:
- server itu technically bisa berada di multiple datacenter/timezone
- client juga dapat mengakses server dari berbagai lokasi/timezone
- ip address juga selalu berubah tergantung koneksi & lokasi user
dari video mas eko di atas juga dijelaskan yang berbahaya adalah : menyimpan data time (tanggal & jam) tanpa menyimpan timezone nya, sehingga dari sisi app level harus tahu data time yang diterima dari database tersebut berada di timezone mana. cmiiw
@@andregandawida pakai suffix WIT/WIB juga bisa. itu berlaku untuk data realtime. untuk data yang membutuhkan integritas di kemudian hari wajib berdasarkan darimana asal data tersebut dimasukkan.
contoh, data skripsi virus insert dari papua tanggal 24 maret 2999 23:00:00. kemudian, pembuat skripsi membacanya kembali di 5 Mei 3015. kalau sekedar convertan timezone dari client. saat client pindah timezone akan hilang integritasnya.
Saya juga pakai approach yg sama. Sebenarnya yg penting adalah ketika menyimpan harus menggunakan timezone yg sama. Epoch pun saya pernah dapet pengalaman pait karena Swift (iOS) itu format Epoch nggak sampe miliseconds, harus dikali 1000 dulu. Itu pusing sampai 2 bulan iOS dev nya buat Debugging. Belum lagi kalau dr Client kirimnya milis gt ada kemungkinan salah konversi, yg di konversi ke milis timezone nya jg beda dr server. Bakal Civil War antar Developer 😅
Thank you kang Eko, superb membantu nih. Biasanya kita simpan date as string biar bisa simpan sampai timezone. Pakai epoch lebih mantap, untuk prevent format waktu yang gak kita inginkan dari FE.
mantap mas. ini yang saya cari2. terima kasih buat pencerahannya
mantap kang, langsung dipraktekan dan ok sekali hasilnya
sehat selalu kang Eko
Mulai hari ini saya tidak akan pernah menggunakan tipe data date dan family nya lagi untuk menyimpan data berbentuk tanggal dan waktu. Thanks om
yg ngikutin course JavaScript nya kang Eko pasti langsung paham dan tambah jelas setalah nyimak ini, mantap kang.. lanjut...
Lanjutkan 👍
Baru kepikiran Kang dan baru sadar harus ngerubah sisi backendnya.
emang paling males ngehandle beda timezone, ruwet sekali
thank you untun informasinya 🔥
Pada embeded system, penggunaan epoch time adalah hal wajib. Anda tidak akan tahu perangkat berada di zona waktu mana. Embeded menggunakan epoch second uint64 (64bit), karena epoch milis boros memory. Sekitaran 2000 an (jaman 32 bit) epoch second yang digunakan adalah int32 sehingga akan roll-over pada (03:14:07 UTC 19 January 2038 ) [Epochalypse the Friday 13th Bug], hal ini bisa ditemukan di perangkat-perangkat GPS tracker (offline).
Oh ya, ada hal yang terlewat. penggunaan epoch time (second/milis) menggindarkan dari masalah zona waktu yang menggunakan Daylight Saving Time (DST) (Summer time). Waktu lokal dapat maju/mundur tergantung pada tanggal dan zona waktu.
Gokil, mind blowing banget ternyata ada sesuatu yang se simple ini untuk menangani Date dll😅
dapat ilmu baru, terima kasih Pak EKO🙏🙏
Sangat inspiratif buat kita semua, langsung implementasi, terimakasih mas eko, sehat selalu dan sukses
sangat bermanfaat
thanks, Pak Eko
Terimakasih kang, meskipun belum dapet case nya.. tapi bisa coba terapin ke project pribadi 😁
Keren pak Eko
Panutan memang
masih kang eko, saya lagi ngerasain kasusnya wkwkwkwkwk emang ribet parah kadang2 error pas manggil API kalo pake tide data `DateTime` biasa, makasih banyak kang
Terima kasih banyak mas. Trick ini benar-benar menyelamatkan hidup saya kwwkwk
Solusi yang diberikan dengan rinci dan jelas. Tengkiu pak eko
akhirnya ketemu solusinya, dari dulu kepikiran ini terus
nice, jam terbangmu tinggi om.. melayang
Baru tau kalau ada problem gini, nambah lagi nih cakrawala pengetahuan, thx kang.
BTW, lampu nya kelihatan di kacamatanya hehehe
Saya hampir saja menggunakan postgresql timestamptz digabung dengan php date('Y-m-d H:i:s O');
Bagus nih cara om kur buat jadi pertimbangan.
Kalau pengalaman saya di erp odoo, kalau ngak salah saya lihat didatabase mereka, itu disimpan dalam utc. Jadi setiap client itu dikasih opsi konfigurasi timezone di akun mereka. lalu ada orm juga untuk nangani masalah date ini kalau ngak salah. jadi kalau query pakai orm bakal di ubah ke timezone utc. cuman permasalahannya kalau querynya complex dan harus raw query, atau kalau buat proses output berupa print sih.
thanks pak, jadi pelajaran baru!
Saya dulu pernah bikin aplikasi pakai api telegram, mereka juga pakai unix timestamp seperti itu untuk tanggal dan jam pesannya. Di sisi aplikasi saya, tinggal konversi ke tanggal lokal untuk tampilannya
hehe bisa di coba ini nih makasih kang eko
Sebelumnya malah ga kepikiran hal ini 😅. Terimakasih mas Eko untuk sharing nya.
Terima kasih tipsnya pak, semoga ke depannya dapet proyek yg negbutuhin ini
menurut saya masih lebih simple cara yang disimpan pake date bg yg formatnya timestamp atau ISO date dan datanya lebih mudah dibaca kalau untuk debugging, timestamp di database best practice nya harus disimpan dalam timezone UTC+0 , dan nanti kalau ada request dari client yg timezonenya beda2 tinggal di convert aja jadi UTC lalu save di database ...
ilmu yg sangat berguna, terimakasih pak eko
Ini yang namanya pengalaman 😎
Thank you pak Eko 😀
Terima kasih banyak pak kebetulan lg dpt masalah kya gini🙏
sangat menginspirasii mas eko👍
Terima kasih Pak Eko... ini sangat membantu 🙏. ditunggu video grpc golang ya pak...
4:01
Haha.. Acak Kadut.
------------------------
Di beberapa pengalaman coding Integrasi dengan EDC Terminal (pake .NET dan C#). Kebanyakan requirement SDK dari Vendornya memang pakai Unix Epoch Time
Mantap penjelasannya.
daging semua nih, makasih banyak pak eko
sangat bermanfaat kang dari sisi programmer, saya juga pernah kena masalah di zona waktu...
mau tanya juga kang, kalau simpan data waktu di DB atau dari sisi API balikin data waktu by unixTime, dari sisi QA (bukan QA engineer) untuk checking datanya nya gimana ya kang? kaya yang tadi createdDate, TransactionDate dll, kayaknya dari sisi mereka yang jadinya agak ribet.
soalnya di tempat saya bekerja, QA itu sering check Data by DB atau Json....
atau teman2 yg lain mau sharing bleh banget nihh..
thanks
Mantaappp bener, terima kasih ilmunyaaa
Kekurangany untuk query harus konversi Satu2 menggunkan foreach which Akan tambah waktu response
sangat simple tapi bener bener membantu
mantap👍👍👍
langsung praktekin!😆
yup, gw juga selalu pake epoch time 👌🏻
Mantap sodaraku 👍🏻👍🏻 terimakasih banyak udh berbagai ilmunya 👍🏻🙏 semoga makin sukses sehat selalu y 🤲🤲 salam silaturahmi y bosku 🙏🙏
Saya lebih memilih pakai ISO-8601. Postgres juga bisa menerima ISO-8601. Banyak bahasa pemrograman juga sudah mendukung ISO-8601. Keuntungan dari ISO-8601 adalah: bisa dibaca oleh manusia, dan kita juga bisa pertahankan TZ yang dianjurkan klien/server.
Untuk presentasi, sepakat kita bisa simpan saja preferensi TZ client, untuk kemudian client bisa melakukan konversi timestampnya ke TZ yang mereka butuhkan.
nah bener. bisa pake ISO8601 cuma convert antar timezonenya lebih ribet dibanding disimpan sebagai epoch time
kalau di mysql bisa kah bang pake format timestamp?
Menarik ini pertanyaannya 👍
Enaknya pakai Epoch, kalau app kita untuk visualisasi data bisa melihat berdasarkan 30 hari terakhir, 15 hari terakhir, dll.
Hanya saja tidak human-friendly menurut saya
Terimakasih pak eko, Sangat bermanfaat!
Kalau saya lebih suka pakai ISO format karena lebih mudah dibaca dan tetap standar. Contoh penulisan ISO adalah 2022-08-12T02:58:04Z. Tapi kalau terpaksa banget harus menyimpan timezone tinggal kita tambahkan saja di belakang contohnya 2022-08-12T02:58:04+07:00
mas, kalau ini tipe datanya di database apa ya? tetap pake varchar atau timestamptz?
soalnya, kalau saya pake timestamptz, timezonenya tetap ngikut server.
saya cuma FE newbie dengerin ini nyambung tp ga ngerti dan ga kebayang implementasinya wkwkw gapapalah nanti juga ngerti dikit2 wkwkw
thank you mas eko, sangat membantu
thanks banget mass 😁👍
Terimakasih mas Eko
Saya ceritanya beda lagi, terbiasa dg mysql langsung insert string tipe data datetime. di SQL server gak bisa.
alhasil ada issue2 lainnya muncul
Baru ketemu reason nya kenapa kalau get api2 produk luar selalu unix epoch tuntuk field2 yg menunjukan waktu
Baru2 ini soalnya lagi sering2 ngulik api spotify
masukkkk pak eko!
Hatur nuhun ilmunya Pak
kalau handle data multi timezone sekedar pakai epoch timezone dari client bakal ada bug, bagusnya itu saat insert ada 2 data, timezone server dan timezone client, ketika data client pada saat insert dan ditampilkan di waktu berbeda. ex, server di jakarta, client di papua. data dimasukkan dari timezone papua, lalu client pergi ke kalimantan timezonenya beda lagi. sebaiknya data yang ditampilkan berdasarkan beberapa data tambahan lain seperti, ip client, user agent browser, dan data2 lain. fungsi untuk verifikasi client komplain kedepannya, jika client insert data dari papua, tapi komplain dari kalimantan. dicatatan client taunya jam 2 saat di papua, di kalimantan jam 1 saat ini. epoch unix gak tau hal beginian, disini terjadi masalahnya. mau pakai date, timestamp, epoch unix. tetap akan mengalami hal beginian, jadi harus diketahui data apa yang ditampilkan, jadi bisa diambil keputusan mau data waktu disesuaikan timezone system pengguna, atau sesuai darimana timezone tersebut dimasukkan.
ga perlu , timezone di hp/laptop itu udah otomatis detect lokasi, kecuali dia ga aktifin timezone otomatis nya. klo client komplain suruh cek tanggal/jam di devicenya sesuai ngga
@@danielalexander4265 kayaknya u gak paham yang gua maksud. benar, hp otomatis detek timezone. u simak yang kujelasin. lo sekarang ada di papua, timezone papua. insert data ke server jakarta timezone barat. selisih 2 jam. terus kau pindah ke kalimantan selisih 1 jam dari server.
kalau cuman sekedar ngikutin timezone client, pas kau insert aja timestamp ditambahin 2 jam. pas client ke kalimantan. server tetap mengirim timestamp ditambah 2 jam. tapi sama timezone system client di kurangi 1 jam. disini letak permasalahannya.
sedangkan, saat dikalimantan client taunya dia insert data pas dipapua jam 2. bukan jam 1. belum lagi kalau bicara akurasi ke menit.
sebaiknya, insertkan data waktu keterangan timezone server dan timezone client.
@@davidstephen7070 engga gitu konsep multiple timezone mah
misal di papua insert jam 2
Liat dikalimantan munculnya ya pasti jam 1 (yang dipapua insert datanya pada jam 1 waktu kalimantan)
Klo malah munculnya jam 2 malah jadi problem lagi, misal sekarang dikalimantan masih jam 1:30 kok timestamp datanya jam 2
Klo misal mau kaya diatas artinya emang perlu modifikasi opsional nambahin timezone client pas insert, bukan bug di epoch nya 😃
@@danielalexander4265 maksud gua bug itu bukan epochnya tapi managemen sistem bakal nimbulin masalah.
u gak paham yang sedang dibicarakan. misalnya, ini lo buat skripsi tentang politik lo insert nih dari papua selisih 2 jam.
setelah berjalan 3 bulan, lo dikalimantan, lo list semua skripsi lo dari database, termasuk skripsi politik itu. kira2 lo nampilin waktu pembuatan skripsi sesuai timezone dimana sekarang timezone client?
kalau lo sekedar gitu, buyar itu intergritas datanya.
makanya, gak cukup sekedar pakai 1 timezone server hasil convertan dari timezone client. harus insert barengan keduanya. lebih bagus lagi ada tambahan data lain dari client berupa ip address.
@@davidstephen7070 ya balik lagi tergantung requirement apps nya, klo tanpa detail data lain bukan berarti jadi bug. Misal whatsapp, shopee, dll dia cuma simpen epoch doang pun ga ada masalah
saya alami sendiri ketika membuatkan app absensi berbasis lokasi dan waktu
gokil. makasih pak eko
Terimakasih banyak pak....
Mantab Pak eko
mas Eko , mau nanyak... mas nya bisa se-expert sekarang dan bisa belajar banyak tentang teknologi dan bahasa pemrograman itu , mas nya belajar + baca dokumentasi + praktekan langsung apa modal cuma sering2 baca dokumentasi atau hal lain doang .
Salama bang terima kasih infonya
Sekarang saya baru merasakannya mas eko, multi timezone 🥲🥵
Biasanya saya pake ISO 8601 untuk date, yg dibelakangnya udh ada timezone nya
makasi banyak mas
terima kasih bang
Kalau saya biasa pakai utc_timestamp() dan ketika ditranslasikan menggunakan convert_tz()
mantap👍🏻🙏🏻
Thank you mas eko
Thank infonya
keren, suwoon bang
Belum pernah merhatiin penggunaan date,
Tapi tanpa sadar rupanya udah sering implementasi di PHP,
walaupun jadinya terkadang angkanya gak manusiawi (human readable), hahahaha
Agak sedikit membingungkan untuk pemula yang belum pernah mengimplementasikannya, mungkin kang eko boleh buat tutorial dari bahasa yg populer seperti php atau js?
Intinya sih konversi ke format tanggalnya kayak yyyy/mm/dd itu di client / frontend bukan dari backend, backend cuman ngasih epoch format aja karna itu value yang sifatnya universal.
Dulu anggapnya datetime bentuk number itu sesuai waktu server, ternyata UTC😅
Wah iya saya coba pake unix akurat gak ribet. Tinggal new Date().getHours() dll
Pernah make moment js di server, konversi waktu bawaan mongodb, eh malah kadang gak update
Halo mau tanya, kalo pake kaya di video, misal saya ke sebuah web, melakukan transaksi di GMT +7 (jakarta), di save transaksinya pake epoch. kalau saya pindah timezone, berarti ketika saya buka history transaksi, itu createdAt nya berubah sesuai lokasi user dong? jadi berubah" kalo kita pindah tempat?
jangan pakai epoch, tapi, fix date sesuai multizone client dan server. kalau pakai epoch masalahnya seperti yang u jelasin. ditable harus ada informasi kapan data tersebut diinsert ke server, dan data waktu dari client, terus disertai informasi lain untuk menguatkan asal data tersebut seperti ip_address. jika, data tersebut penting. seperti, pembuatan skripsi dari papua.
Genius om hahaha
Bang, buat tutorial pembuatan aplikasi versi abang dong..
"nightmare" buat programer, klasik
kaget saya, masak masalah seperti ini masih mengganggu para master? saya yang pemula merasa jadi di atas angin ini.
terimakasih om
untuk json nya apakah lebih baik pakai string om? soalnya bisa tergantung bahasa pemrogramannya max value integer nya berapa
nah ini nih.
Best practice biasanya pakeknya bentuk UNIX Timestamp atau timestamp biasa sih ?
unix timestamp? bukannya timestamp hanya menampung data hinggan januari 2038?. Berarti, jika saya simpan ke dalam tipedata BIGINT. Apa bisa bertahan hingga lebih dari 2038?
bang tolong di ulas kasus perhitungan jam lembur yang lewat hari dengan fungsi date time donk
makasih sebelumnya
Biasanya disetor di databasenya make tipe data integer ya, bang? Saya barusan nyari, yang 4 byte bisa kena Year 2038 problem, berarti lgsg make yg 8 byte?
iya, pake tipe LONG
@@ProgrammerZamanNow Oke, bang. Terima kasih jawabannya. Sukses selalu, bang 😊
Pas banget skrng lagi permasalahan gini tapi masalahnya datanya udah banyak. Mau pindah ke epoc gbs akhirnya timezonenya figanti ke UTC :v
Knp gak pake datetimeoffset kang? Biar mempermudah query?
meski pakai UTC, akan tetap jadi masalah ketika backend masih pakai frame GMT tertentu (misal GMT+7), akhirnya terpaksa harus konversi dari GMT berbeda ke GMT yang dipakai backend :D. Sempat punya masalah dengan backend seperti ini, akhirya ya harus main konversi2 gitu di frontendnya
UTC itu bukannya GMT+0 ya
acakadut kang,bahasa naon eta haha
berarti kita tidak bisa langsung lihat data date time di database nya ya? kalau mau nge query manual di database buat ngeliat data date time, mesti di copy dulu ke excel atau platform lainnya buat nge convert unix epoch nya
kalau di pgsql ada function to_timestamp(epoch/1000)::date atau ::timestamp buat ngubah jadi format tanggal, ini bisa ditambahin di query nya
pertanyaan yang sama.
berarti harus query dan format dulu ya buat tau waktunya.