API Kalender MABIMS | Blog

Kenapa Tanggal Hijriah Berganti Saat Maghrib (dan Cara Menanganinya)

Sat, 19 Sep 2026 00:00:00 GMT

Ini bagian yang sering luput dari developer yang bikin fitur tanggal Hijriah. Kita terbiasa dengan pola “ganti hari jam 00:00”, jadi refleks kita ya ambil tanggal hari ini, tampilkan, selesai. Padahal buat kalender Hijriah, itu setengah benar.

Di tulisan ini kita bahas dua hal: kenapa hari Hijriah dimulai saat maghrib, dan bagaimana parameter next=true di GET /today bisa bantu kamu menanganinya tanpa ribet.

Kenapa hari Hijriah dimulai saat maghrib?

Kalender Masehi itu harinya dihitung dari satu tengah malam ke tengah malam berikutnya, murni konvensi. Semacam kesepakatan bersama negara-negara dunia gitu.

Kalender Hijriah beda. Dia kalender bulan, dan awal bulannya ditentukan lewat pengamatan hilal, bulan sabit tipis pertama yang muncul setelah bulan baru. Hilal itu hanya bisa dilihat (atau dihitung kriterianya) saat matahari terbenam, di ufuk barat, sebentar setelah maghrib.

Jadi logikanya begini:

matahari terbenam (maghrib)
        ↓
hilal diamati / kriterianya diperiksa
        ↓
kalau memenuhi, bulan baru dimulai
        ↓
hari pertama bulan baru dimulai SEKARANG, bukan nunggu tengah malam

Karena penentuan bulan baru terjadi di maghrib, wajar kalau batas pergantian hari-nya juga ikut di maghrib. Hari Hijriah berjalan dari maghrib ke maghrib.

Kalau kamu pernah baca deep dive mabims-computed, ini nyambung. Kriteria Neo MABIMS (ketinggian hilal minimal 3° dan elongasi minimal 6,4°) diperiksa saat matahari terbenam. Titik waktu yang sama itulah yang jadi patokan pergantian hari.

Contoh yang paling gampang: malam pertama Ramadan

Ini contoh yang semua orang Indonesia pernah alami.

Misalnya 1 Ramadan jatuh pada hari Rabu menurut penanggalan Masehi. Kapan tarawih pertama? Selasa malam.

Kok bisa? Karena Selasa sore setelah maghrib, tanggal Hijriah sudah masuk 1 Ramadan. Malamnya sudah malam Ramadan, jadi tarawih dan sahur-nya ikut. Baru besoknya, hari Rabu, kita puasa hari pertama (ini juga alasan kenapa Sabtu malam disebut malam Minggu).

Jadi di Selasa jam 19:00, kalender Masehi bilang “Selasa”, tapi kalender Hijriah sudah bilang “1 Ramadan”. Dua-duanya benar, cuma batas harinya beda.

Hal yang sama berlaku untuk malam Jumat, malam 1 Muharram, malam Idul Fitri (malam takbiran), dan seterusnya. Semua “malam” itu sebenarnya sudah bagian dari hari berikutnya.

Masalahnya buat developer

Sekarang bayangkan kamu bikin widget tanggal Hijriah di website masjid. Kamu panggil /today seperti biasa:

curl "https://api.mabims.dev/api/v1/today?tz=Asia/Jakarta"

Responsnya:

{
  "input": { "date": "2026-08-24", "calendar": "gregorian", "tz": "Asia/Jakarta" },
  "output": { "date": "1448-03-11", "calendar": "hijri", "day": 11, "month": 3, "month_name": "Rabiul Akhir", "year": 1448, "weekday": "Senin" },
  "source": "mabims",
  "warnings": []
}

Ini benar untuk siang hari. Tapi jam 18:30 WIB, jamaah yang buka website itu secara syar’i sudah masuk tanggal 12 Rabiul Akhir, sementara widget kamu masih nampilin 11. Baru jam 00:00 nanti widget-nya “menyusul”.

Selisih ±5 sampai 6 jam itu kelihatannya kecil, tapi buat website masjid, pesantren, atau aplikasi pengingat puasa (puasa Ayyamul Bidh, Senin Kamis, Asyura, dan sebagainya), tanggalnya bisa bikin bingung. Apalagi kalau malam itu memang malam yang penting.

Solusinya: `next=true`

Makanya /today punya parameter next. Cara pakainya:

curl "https://api.mabims.dev/api/v1/today?tz=Asia/Jakarta&next=true"

Responsnya sekarang punya satu objek tambahan bernama next:

{
  "input": { "date": "2026-08-24", "calendar": "gregorian", "tz": "Asia/Jakarta" },
  "output": { "date": "1448-03-11", "calendar": "hijri", "day": 11, "month": 3, "month_name": "Rabiul Akhir", "year": 1448, "weekday": "Senin" },
  "next": { "date": "1448-03-12", "calendar": "hijri", "day": 12, "month": 3, "month_name": "Rabiul Akhir", "year": 1448, "source": "mabims" },
  "source": "mabims",
  "warnings": []
}

Artinya:

output = tanggal Hijriah sekarang (sebelum maghrib).
next = tanggal Hijriah yang berlaku setelah maghrib malam ini.

Jadi satu kali request, kamu dapat dua-duanya. Tinggal pilih mana yang ditampilkan tergantung sekarang sudah lewat maghrib atau belum.

Tanpa next=true, field next nggak muncul sama sekali dan respons-nya sama persis seperti sebelumnya. Jadi kode lama kamu aman, nggak ada yang rusak.

Satu hal penting: API nggak menghitung waktu maghrib

Ini bagian yang perlu kamu baca baik-baik.

API ini nggak tahu jam berapa maghrib di tempatmu. Dia cuma ngasih dua kandidat tanggal, output dan next. Kapan harus pindah dari yang pertama ke yang kedua, itu urusan sisi klien.

Ini masuk akal kalau dipikir-pikir: waktu maghrib bergantung pada lokasi yang spesifik (kota, bahkan koordinat), dan berubah tiap hari. maghrib di Jakarta, Malang, Makassar, dan Jayapura beda-beda. Jadi API tetap fokus di hal yang dia kuasai, yaitu tanggal Hijriah, dan waktu maghrib kamu ambil dari sumber jadwal sholat yang sesuai lokasi pengguna kamu.

Sumbernya bebas: library jadwal sholat, API jadwal sholat, atau data jadwal yang sudah kamu punya di aplikasi (kalau aplikasimu memang sudah menampilkan waktu sholat, tinggal pakai waktu maghrib yang sama).

Contoh implementasi JavaScript

async function ambilTanggalHijriah(waktumaghrib) {
  const res = await fetch(
    "https://api.mabims.dev/api/v1/today?tz=Asia/Jakarta&next=true"
  );
  const data = await res.json();

  // waktumaghrib adalah objek Date untuk maghrib hari ini di lokasi user
  const sudahmaghrib = new Date() >= waktumaghrib;

  return sudahmaghrib ? data.next : data.output;
}

Lalu tinggal ditampilkan seperti biasa:

const waktumaghrib = ambilWaktumaghribHariIni(); // dari sumber jadwal sholat kamu
const tanggal = await ambilTanggalHijriah(waktumaghrib);

const { day, month_name, year } = tanggal;
document.querySelector("#hijri-date").textContent =
  `${day} ${month_name} ${year} H`;

Sebelum maghrib tampil 11 Rabiul Akhir 1448 H, setelah maghrib otomatis jadi 12 Rabiul Akhir 1448 H.

Sisi bagusnya, kamu nggak perlu request ulang saat maghrib tiba. Data output dan next sudah ada dari awal, jadi cukup satu kali fetch, lalu bandingkan dengan jam saat ini (misalnya pakai setInterval atau cek tiap kali komponen dirender).

Bagaimana kalau lewat tengah malam?

Setelah jam 00:00, kalender Masehi ganti hari, dan /today otomatis mengembalikan output yang sudah berisi tanggal Hijriah baru. Nilainya sama dengan next yang kemarin kamu ambil malam sebelumnya.

Jadi next=true itu relevan di jendela waktu maghrib sampai tengah malam. Di luar jendela itu, output saja sudah cukup. Nggak masalah kalau kamu tetap selalu kirim next=true, hasilnya tetap konsisten.

Timezone dan maghrib itu satu paket

Kalau kamu baca tutorial integrasi, saya sudah bahas soal parameter tz. Di sini timezone jadi makin penting.

next=true selalu dihitung relatif terhadap “hari ini” di timezone yang kamu kirim. Jadi kalau user kamu di Makassar, kirim tz=Asia/Makassar. Kalau di Jayapura, kirim tz=Asia/Jayapura. Kalau tidak diisi, bawaannya Asia/Jakarta.

Kolom input.tz di respons akan menampilkan zona waktu yang dipakai, jadi kamu bisa memastikan API menghitung di zona yang benar.

Jangan lupa cek `next.source`

Objek next punya field source sendiri, terpisah dari source utama. Kenapa?

Karena tanggal besok bisa saja berada di luar tabel resmi Kemenag walaupun tanggal hari ini masih di dalam tabel. Misalnya hari ini adalah hari terakhir yang tercakup tabel. Maka source utama mabims, tapi next.source bisa jadi mabims-computed.

if (data.next?.source === "mabims-computed") {
  console.warn("Tanggal setelah maghrib dihitung dengan kriteria Neo MABIMS, bukan tabel resmi.");
}

Ini sejalan dengan prinsip yang sama di API ini: saya nggak mau hasil perhitungan diam-diam tampil seolah-olah data resmi. Kalau kamu mau tahu lebih lanjut soal bedanya, ada di deep dive mabims-computed.

Soal cache

/today di-cache di edge sampai tengah malam lokal. Ini aman untuk next=true karena output dan next sama-sama berlaku sepanjang hari itu. Pergantian dari output ke next terjadi di sisi klien, bukan di server, jadi cache nggak akan bikin tanggal “nyangkut”.

Tapi ada satu jebakan kalau kamu bikin cache sendiri di sisi server (misalnya di WordPress atau PHP seperti di tutorial sebelumnya):

Jangan simpan hasil akhir yang sudah dipilih. Simpan respons mentahnya (output dan next), lalu tentukan mana yang tampil setiap kali halaman dirender.

Kalau kamu cache string "11 Rabiul Akhir 1448 H" selama 1 jam, widget kamu bisa tetap nampilin tanggal lama sampai 1 jam setelah maghrib lewat. Kalau yang kamu cache respons JSON-nya, dan pilihan output vs next dilakukan saat render, tanggalnya tetap tepat waktu.

Error yang mungkin muncul

Parameter next menerima true/false (tidak peka huruf besar/kecil) dan 1/0. Kalau kamu kirim nilai lain, misalnya next=yes, API akan menjawab:

{
  "error": {
    "code": "invalid_next",
    "message": "..."
  }
}

dengan HTTP status 400. Jadi kalau tiba-tiba widget kamu kosong setelah menambah parameter ini, cek dulu nilainya.

Ringkasan

Hari Hijriah dimulai saat maghrib, bukan tengah malam, karena bulan baru ditentukan lewat hilal yang diperiksa saat matahari terbenam.
Akibatnya, dari maghrib sampai tengah malam, tanggal Hijriah sudah “besok” padahal tanggal Masehi masih hari yang sama.
Pakai ?next=true di GET /today untuk mendapatkan objek next, yaitu tanggal Hijriah yang berlaku setelah maghrib malam ini.
API tidak menghitung waktu maghrib. Kamu yang menentukan kapan berpindah dari output ke next, pakai waktu maghrib sesuai lokasi pengguna.
Kirim tz yang sesuai, cek next.source, dan kalau kamu bikin cache sendiri, simpan respons mentah, bukan hasil akhirnya.

Coba sekarang:

curl "https://api.mabims.dev/api/v1/today?tz=Asia/Jakarta&next=true"

Dokumentasi lengkap endpoint ini ada di mabims.dev/endpoints/today. Pengguna non-developer bisa langsung melihat efek pergantian saat maghrib lewat kalender Hijriah MABIMS. Kalau ada kasus yang belum tertangani atau kamu nemu tanggal yang terasa janggal, silakan buka issue di GitHub.

Semoga widget tanggal Hijriah kamu nggak pernah lagi telat sehari :)

Cara Integrasi MABIMS API ke Aplikasi iOS & Android

Sat, 12 Sep 2026 00:00:00 GMT

Di post sebelumnya kita bahas cara nampilin tanggal Hijriah di website: tinggal fetch /today, cache sejam di server, selesai. Gampang, karena web itu asumsinya selalu online.

App mobile beda cerita. User bisa buka app pas mode pesawat, di daerah sinyal lemah, atau bahkan sengaja mode offline. Kalau app cuma andelin fetch('/today') tanpa fallback, begitu offline ya tanggal Hijriah-nya nggak muncul sama sekali. Untuk widget masjid/pesantren atau app ibadah, itu masalah beneran, bukan cuma UX yang kurang mulus.

Jadi buat native app (Swift/Kotlin), strateginya perlu 2 lapis: satu untuk kondisi online (akurat, real-time), satu untuk fallback offline (dari cache lokal).

Kenapa Harus MABIMS (Bukan Umm al-Qura)?

Kalau install library kalender Hijriah dari package manager, hampir semua defaultnya pakai kriteria Umm al-Qura (kalender resmi Arab Saudi), gampang ditemukan, dokumentasinya lengkap, tapi bisa beda ±1 hari dari tanggal yang diumumkan Kemenag RI. Buat app yang dipakai user Indonesia (jadwal puasa, hari besar, dsb), selisih sehari itu bisa bikin awam. Ceritanya lebih lengkap ada di Cerita di Balik MABIMS API, soal kenapa post itu dan API ini dibuat.

Arsitektur 2 Layer

Layer 1: Cache tahunan (/year) sebagai fallback offline

Fetch sekali:

GET https://api.mabims.dev/api/v1/year?year=2026&calendar=gregorian

Pakai calendar=gregorian (bukan hijri), karena kalender Kemenag itu dipublikasikan per tahun Masehi (“Kalender 2026”), jadi lebih natural nyimpen & nge-refresh per tahun Masehi juga. Satu fetch langsung dapet Januari-Desember lengkap, gampang di-lookup dari tanggal device yang juga Masehi.

Simpan hasilnya lokal (Room/SharedPreferences di Android, atau file JSON + UserDefaults di iOS). Ini yang dipakai kalau app lagi offline.

Layer 2: /today live setiap app dibuka & online

GET https://api.mabims.dev/api/v1/today?tz={timezone_device}

Ini source of truth paling akurat, karena bisa nangkep update data terbaru dari Kemenag. Alur baca di app:

Ada koneksi? → hit /today, tampilkan hasilnya.
Gagal (timeout/no network)? → fallback: cari tanggal hari ini di cache /year lokal.

Network-first, bukan cache-first, karena /today murah (response-nya kecil) dan sudah dilayani lewat CDN edge cache dengan TTL yang kedaluwarsa persis tengah malam lokal, jadi hampir nggak pernah nyampe origin.

Kapan Refresh Cache `/year`?

Simpel: terjadwal sekali di akhir Desember, fetch ulang /year untuk tahun Masehi berikutnya (background task: BGAppRefreshTask di iOS, WorkManager periodic di Android).

Satu catatan penting: pendekatan ini sengaja simpel dan cukup buat kebanyakan kasus, karena calendar=gregorian bikin siklus refresh-nya align sama tahun Masehi (bukan tahun Hijriah yang bergeser ~11 hari tiap tahun seperti kalau kita cache per tahun Hijriah). Tapi tetap kasih safety net: kalau suatu saat /today gagal dan hasil lookup dari cache ternyata nggak ketemu (data belum ke-refresh, atau app baru pertama kali dipasang lewat pertengahan tahun), trigger fetch /year on-the-spot saat itu juga, jangan nunggu jadwal Desember berikutnya.

Contoh Kode: Swift (iOS)

import Foundation

struct HijriOutput: Codable {
    let date: String
    let day: Int
    let month: Int
    let month_name: String
    let year: Int
}

struct TodayResponse: Codable {
    let output: HijriOutput
    let source: String
    let warnings: [String]
}

final class HijriRepository {
    private let baseURL = "https://api.mabims.dev/api/v1"
    private let cacheKey = "hijri_year_cache"
    private let cacheYearKey = "hijri_year_cache_year"

    // Layer 2: live, dipanggil tiap app dibuka
    func today() async -> (date: String, warnings: [String]) {
        let tz = TimeZone.current.identifier
        if let url = URL(string: "\(baseURL)/today?tz=\(tz)") {
            if let (data, _) = try? await URLSession.shared.data(from: url),
               let decoded = try? JSONDecoder().decode(TodayResponse.self, from: data) {
                return (decoded.output.date, decoded.warnings)
            }
        }
        // fallback ke cache lokal
        return fallbackFromCache() ?? ("-", [])
    }

    private func fallbackFromCache() -> (String, [String])? {
        guard let cached = UserDefaults.standard.data(forKey: cacheKey) else { return nil }
        // parse & cari entry yang tanggal gregorian-nya == hari ini
        // (struktur /year: { months: { "1": [...], "2": [...] } })
        // ...lookup logic sesuai model kamu
        return nil // placeholder
    }

    // Layer 1: refresh tahunan, dipanggil dari BGAppRefreshTask akhir Desember
    // atau on-the-spot kalau fallback gagal nemu data
    func refreshYearCache(year: Int) async {
        guard let url = URL(string: "\(baseURL)/year?year=\(year)&calendar=gregorian") else { return }
        if let (data, _) = try? await URLSession.shared.data(from: url) {
            UserDefaults.standard.set(data, forKey: cacheKey)
            UserDefaults.standard.set(year, forKey: cacheYearKey)
        }
    }
}

Daftarin refresh task di AppDelegate/SceneDelegate pakai BGTaskScheduler, jadwalin sekali per tahun sekitar 28–31 Desember.

Contoh Kode: Kotlin (Android)

data class HijriOutput(
    val date: String, val day: Int, val month: Int,
    val month_name: String, val year: Int
)
data class TodayResponse(
    val output: HijriOutput, val source: String, val warnings: List<String>
)

class HijriRepository(
    private val api: MabimsApi, // Retrofit interface
    private val prefs: SharedPreferences
) {
    // Layer 2: live, dipanggil tiap app dibuka
    suspend fun today(): Pair<String, List<String>> {
        return try {
            val tz = java.util.TimeZone.getDefault().id
            val response = api.getToday(tz = tz)
            response.output.date to response.warnings
        } catch (e: Exception) {
            fallbackFromCache() ?: ("-" to emptyList())
        }
    }

    private fun fallbackFromCache(): Pair<String, List<String>>? {
        val cachedJson = prefs.getString("hijri_year_cache", null) ?: return null
        // lookup tanggal gregorian hari ini dari cached JSON (/year response)
        return null // placeholder, parsing sesuai model kamu
    }

    // Layer 1: refresh tahunan via WorkManager, akhir Desember
    // atau on-the-spot kalau fallback gagal nemu data
    suspend fun refreshYearCache(year: Int) {
        val response = api.getYear(year = year, calendar = "gregorian")
        prefs.edit().putString("hijri_year_cache", response.toRawJson()).apply()
        prefs.edit().putInt("hijri_year_cache_year", year).apply()
    }
}

Schedule-in lewat WorkManager periodic request (interval 1 tahun, atau lebih praktis: one-time request yang di-reschedule tiap kali jalan, dipicu sekitar akhir Desember).

Edge Case yang Wajib Dipikirin

First launch tanpa internet sama sekali. Kalau app baru diinstall dan langsung dibuka offline, cache /year belum ada. Opsinya: bundle snapshot data minimal di dalam app (assets/res/raw di Android, bundle resource di iOS), atau paksa user online sekali di onboarding.
Timezone. Jangan hardcode Asia/Jakarta. Ambil dari TimeZone.current.identifier (Swift) atau TimeZone.getDefault().id (Kotlin), kirim sebagai param tz.
Field warnings. Kalau nggak kosong (misalnya tanggal deket ambang visibilitas hilal), tampilkan indikator kecil di UI, misalnya “bisa geser 1 hari dari pengumuman resmi”, biar user nggak kaget kalau nanti ada revisi.

Bonus: Pakai React Native/Expo?

Kalau stack-nya React Native, alternatif yang lebih simpel: pakai package mabims-hijri, data 2023-2026 udah dibundle langsung di package, jadi nggak perlu arsitektur cache manual sama sekali untuk kasus umum.

npm install mabims-hijri

Penutup

Referensi lengkap tiap endpoint ada di:

Kalau app kamu butuh rate limit lebih tinggi atau SLA (misal buat app skala besar), hubungi halo@pixostudio.id.

Visibilitas Hilal Rabiul Akhir 1448 H

Fri, 11 Sep 2026 00:00:00 GMT

Apakah Rabiul Awal 1448 H berlangsung 29 hari atau 30 hari? Mari kita lihat datanya.

Untuk menjawab pertanyaan itu, kita perlu melihat keadaan hilal pada sore 11 September 2026, bertepatan dengan 29 Rabiul Awal 1448 H. Jika hilal belum memenuhi kriteria, secara perhitungan bulan berjalan digenapkan menjadi 30 hari dan Rabiul Akhir dimulai setelahnya.

Melihat petanya dulu

Saya mulai dari peta karena gambaran besarnya langsung terlihat. Tidak ada titik yang memenuhi kriteria, sedangkan 95 titik tidak memenuhi. Lokasi dengan hasil paling baik adalah Meulaboh Coast, di pesisir barat Aceh. Bahkan di sana pun hasilnya masih belum cukup.

Peta ini memeriksa wilayah Indonesia dari banyak titik. Jadi, kesimpulannya bukan hanya karena pengamatan di satu tempat kurang baik. Pada sore itu, Bulan memang masih terlalu rendah dan terlalu dekat dengan Matahari di seluruh wilayah yang diperiksa.

Lalu, apa yang terjadi di langit?

Gambar langit membantu menjelaskan angka-angka di peta. Di Meulaboh Coast, ketinggian Bulan hanya 1,4°. Jarak sudutnya dari Matahari juga baru 4,8°.

Padahal, kriteria Neo MABIMS mensyaratkan ketinggian Bulan minimal 3,0° dan jarak sudut (elongasi) minimal 6,4°. Kedua syarat ini harus terpenuhi sekaligus. Karena keduanya belum tercapai, gambar tersebut menampilkan status TIDAK MEMENUHI.

Sebagai pengingat, angka 3 dan 6,4 derajat ini adalah hasil penelitian ratusan pengamatan hilal (lihat ANTARA dan Jurnal Al-Marshad). Kesimpulannya? Di bawah angka tersebut hilal mustahil dilihat dengan mata telanjang maupun dengan alat bantu teleskop.

Keadaan di ufuk juga kurang mendukung. Matahari terbenam pukul 18.36, sementara Bulan terbenam pukul 18.41. Waktu pengamatannya hanya sekitar lima menit. Bagian Bulan yang disinari Matahari pun baru 0,1 persen, sehingga sabitnya masih sangat tipis.

Kesimpulan

Dari data ini, Rabiul Awal 1448 H belum memenuhi kriteria Neo MABIMS pada sore 11 September 2026. Dengan demikian, menurut kriteria tersebut, Rabiul Awal digenapkan menjadi 30 hari dan awal Rabiul Akhir jatuh setelahnya.

Ini adalah hasil perhitungan visibilitas, bukan keputusan resmi penetapan awal bulan. Keputusan resmi tetap mengikuti proses rukyat dan sidang isbat oleh pihak yang berwenang.

Data lengkap tersedia melalui data hilal MABIMS dan visualisasi hilal. Mau memeriksa bulan lain? Buka kalender Hijriah dan lihat periode masing-masing bulan beserta data hilalnya.

Bedah mabims-computed: Apa yang Terjadi di Balik Layar?

Wed, 09 Sep 2026 00:00:00 GMT

Di beberapa bagian dokumentasi MABIMS API, saya menyebut source: "mabims-computed" sebagai fallback.

Di tulisan ini kita akan melihat cara kerjanya lebih dekat. mabims-computed bukan sekadar “kalau datanya tidak ada, pakai perkiraan”. Di baliknya ada mesin kecil yang menghitung awal bulan Hijriah, berjalan maju atau mundur dari sebuah tanggal acuan, menyimpan hasil perhitungan, lalu memberi tahu aplikasi bahwa data yang diterima bukan data resmi Kemenag.

Saya akan membahas bagian-bagian yang biasanya tidak terlihat dari luar: bagaimana mesin menentukan sebuah bulan memiliki 29 atau 30 hari, mengapa ketinggian hilal dihitung secara toposentris sementara elongasi tetap geosentris, dan mengapa kriteria tersebut diperiksa di 25 titik pengamatan pesisir.

Dua jenis data, satu API

MABIMS API memiliki dua sumber data utama:

mabims — tanggal dari kalender publik Kemenag RI.
mabims-computed — tanggal yang dihitung menggunakan kriteria Neo MABIMS ketika tanggal tersebut berada di luar cakupan tabel.

Contoh tanggal yang masih tersedia di dalam tabel:

{
  "output": {
    "date": "1447-09-01",
    "calendar": "hijri",
    "day": 1,
    "month": 9,
    "month_name": "Ramadhan",
    "year": 1447,
    "weekday": "Kamis"
  },
  "source": "mabims",
  "warnings": []
}

Kalau tanggal yang diminta sudah berada di luar tabel, bentuk responsnya tetap sama. Yang berubah adalah sumber datanya:

{
  "output": {
    "date": "1450-01-01",
    "calendar": "hijri",
    "day": 1,
    "month": 1,
    "month_name": "Muharram",
    "year": 1450,
    "weekday": "Jumat"
  },
  "source": "mabims-computed",
  "warnings": [
    "Date is outside the curated MABIMS table; computed with the Neo MABIMS criteria (moon altitude >= 3 deg and elongation >= 6.4 deg at local sunset, seen anywhere across the coastal observation sites of Indonesia)."
  ]
}

Kedua sumber ini sengaja dibedakan. Hasil perhitungan tetap berguna untuk kalender aplikasi, tetapi tidak boleh dianggap sebagai pengumuman resmi atau pengganti sidang isbat.

Neo MABIMS dalam dua angka

Versi singkat kriteria Neo MABIMS adalah:

ketinggian hilal >= 3.0°
elongasi         >= 6.4°

Kedua syarat tersebut harus terpenuhi secara bersamaan, dan cukup terpenuhi di satu titik pengamatan saja. Kalo cuma ketinggian hilal yang memenuhi syarat, tetapi elongasinya belum cukup = kriterianya belum terpenuhi. Begitu juga sebaliknya. (Lihat juga liputan ANTARA dan Jurnal Al-Marshad tentang kriteria ini.)

Kriteria ini diperiksa saat matahari terbenam di masing-masing titik pengamatan. Saat ini ada 25 titik pengamatan pesisir dari Sabang sampai Rote; daftar lengkapnya tersedia di api/data/hilal_sites.json. Polanya menarik: pada bulan-bulan yang kondisinya cukup aman, titik paling barat hampir selalu menjadi penentu. Semakin ke barat, matahari terbenam semakin lambat, sehingga hilal berada lebih tinggi di atas horizon saat senja. Namun, pada bulan-bulan ketika deklinasi Bulan berada di selatan, jalur titik-titik di selatan, dari Jawa bagian selatan sampai Nusa Tenggara, bisa menjadi penentu. Itu sebabnya titik-titik selatan juga perlu diperiksa.

Ini bukan berarti Sabang selalu menjadi patokan. Logikanya sama dengan rukyah Kemenag: selama hilal terlihat di wilayah Indonesia, bulan baru dimulai. API bahkan melaporkan titik yang menjadi penentu melalui field deciding_site.

Dari hilal ke panjang bulan

Perhitungan panjang bulan sebenarnya bisa diringkas dalam fungsi kecil:

def month_length(month_start):
    result = criteria_on_day29(month_start)
    return 29 if result.visible else 30

criteria_on_day29() memeriksa kondisi saat matahari terbenam pada malam ke-29 bulan yang sedang berjalan. Kalau kedua kriteria terpenuhi, bulan tersebut selesai setelah 29 hari. Kalau tidak, bulan digenapkan menjadi 30 hari.

Artinya, untuk menentukan awal Ramadan, yang diperiksa bukan malam pertama Ramadan. Yang diperiksa adalah malam ke-29 Sya’ban. Kalau hilal memenuhi kriteria, hari berikutnya adalah 1 Ramadan. Kalau tidak, Sya’ban berlangsung selama 30 hari.

Alurnya kira-kira seperti ini:

awal bulan Hijriah yang sudah diketahui
                 ↓
periksa matahari terbenam pada malam ke-29
                 ↓
ketinggian >= 3° dan elongasi >= 6.4°?
             ↙                         ↘
           ya                          tidak
       bulan 29 hari                bulan 30 hari
             ↓                          ↓
   awal bulan berikutnya = awal + panjang bulan

Karena setiap bulan dimulai setelah bulan sebelumnya berakhir, mesin ini dapat menyusun kalender secara berantai.

Bukan konversi aritmetika biasa

Kalender Hijriah tabular biasanya dapat dihitung dengan pola aritmetika: setiap bulan memiliki susunan 29 dan 30 hari tertentu, lalu siklus tahun kabisat menentukan penempatannya.

mabims-computed tidak bekerja seperti itu. Panjang bulan ditentukan satu per satu berdasarkan kondisi astronomis pada malam ke-29. Jadi, cara kerjanya lebih mirip linked list daripada rumus satu baris:

1449-01-01
   └─ periksa hilal → 29 atau 30 hari
       └─ 1449-02-01
           └─ periksa hilal → 29 atau 30 hari
               └─ 1449-03-01

Konsekuensinya, mesin ini membutuhkan satu titik awal yang tepercaya. Di aplikasi, titik tersebut berasal dari batas tabel resmi Kemenag RI. Untuk tanggal setelah batas tabel, mesin berjalan maju dari tanggal acuan itu.

Bisa berjalan mundur juga

Untuk tanggal sebelum kalender resmi, API tidak langsung mengizinkan perhitungan. Request harus menyertakan retro=true.

Alasannya sederhana: kriteria Neo MABIMS baru diperkenalkan pada 2022. Kalau kriteria tersebut diterapkan ke tahun 1990, hasilnya bukan data historis resmi. Hasil itu adalah rekonstruksi menggunakan aturan yang berlaku sekarang.

Karena itu, ada sumber data ketiga:

source: "mabims-retro"

Label ini berarti tanggal tersebut dihitung mundur menggunakan kriteria yang sama, bukan diambil dari tabel resmi masa lalu. API juga memberikan warning agar perbedaan status ini tidak hilang ketika respons diteruskan ke aplikasi.

Secara internal, berjalan mundur sedikit lebih rumit daripada berjalan maju. Kalau kita mengetahui tanggal 1 bulan berikutnya, kita perlu memeriksa waktu matahari terbenam pada hari ke-31 sebelumnya untuk menentukan apakah bulan sebelumnya memiliki 29 atau 30 hari. Setelah itu, awal bulan sebelumnya bisa ditentukan.

Bagian yang membuat saya harus menyelidiki ulang

Awalnya saya mengira pertanyaannya sederhana: untuk menghitung kriteria hilal, sebaiknya kita memakai koordinat pengamat di permukaan Bumi atau posisi yang dihitung dari pusat Bumi?

Istilahnya:

Toposentris — dilihat dari permukaan Bumi, dengan memperhitungkan posisi pengamat dan paralaks Bulan.
Geosentris — dilihat dari pusat Bumi.

Secara intuisi, pendekatan toposentris memang lebih masuk akal untuk pengamatan hilal karena manusia mengamati dari permukaan Bumi. Setelah saya validasi ulang dari awal sampai akhir, intuisi itu ternyata benar. Mesin ini menggunakan ketinggian hilal secara toposentris (dengan koreksi refraksi atmosfer) di 25 titik pengamatan pesisir dari Sabang sampai Rote. Elongasi tetap dihitung secara geosentris, sesuai konvensi hisab Indonesia. Kriteria cukup terpenuhi di satu titik mana pun.

Kondisi borderline itu nyata

Kembali ke perhitungannya. Memenuhi kriteria bukan berarti posisinya jauh di atas ambang batas.

Misalnya hasilnya seperti ini:

altitude  = 3.12°
elongation = 7.01°

Secara boolean, hasil tersebut memenuhi kriteria. Namun, jarak terdekatnya dari ambang batas ketinggian hanya 0,12°. Karena itu, provider menyimpan margin terkecil:

margin = min(
    altitude - 3.0,
    elongation - 6.4,
)

Kalau margin tersebut positif tetapi kurang dari 0,25°, bulan ditandai sebagai borderline. Informasi ini dimasukkan ke warnings[] agar aplikasi tidak menganggap hasil yang sangat dekat dengan ambang batas sebagai sesuatu yang sepenuhnya pasti.

Catatan penting: borderline bukan berarti hasilnya otomatis salah. Artinya, perubahan kecil pada lokasi, metode, data ephemeris, atau cara menafsirkan kriteria dapat memengaruhi hasil.

Kapan `mabims-computed` boleh digunakan?

Menurut saya, mabims-computed cocok digunakan untuk:

kalender aplikasi yang membutuhkan cakupan tahun lebih panjang;
pratinjau tanggal hari besar di masa depan;
fitur konversi tanggal yang belum memiliki tabel resmi;
riset, eksperimen, dan visualisasi hilal;
fallback teknis ketika data resmi belum tersedia.

Jangan memperlakukannya sebagai:

pengumuman resmi awal Ramadan atau Idul Fitri;
pengganti sidang isbat;
bukti bahwa hilal benar-benar diamati di lokasi tertentu;
satu-satunya sumber untuk mengambil keputusan administratif atau keagamaan.

Di sisi aplikasi, setidaknya selalu periksa dua field berikut:

if (data.source === "mabims-computed") {
  console.warn("Tanggal ini adalah estimasi algoritmik, bukan data resmi.");
}

if (data.warnings?.length) {
  console.warn(data.warnings);
}

Intinya

mabims-computed adalah sebuah kompromi yang dibuat secara sadar:

Tabel resmi digunakan selama datanya tersedia.
Di luar cakupan tabel, panjang bulan dihitung berdasarkan kriteria Neo MABIMS.
Kriteria diperiksa saat matahari terbenam di masing-masing dari 25 titik pengamatan pesisir; cukup satu titik yang memenuhi syarat.
Dua ambang, yaitu ketinggian 3° dan elongasi 6,4°, harus terpenuhi secara bersamaan.
Ketinggian hilal dihitung secara toposentris dengan koreksi refraksi, sedangkan elongasi tetap geosentris. Model ini tervalidasi 48 dari 48 kasus terhadap tabel kurasi.
Hasilnya diberi label dan warning agar tidak disalahartikan sebagai data resmi.

Kalau kamu hanya memanggil /today, semua kerumitan ini memang tidak perlu terlihat. Namun, saat kamu meminta kalender untuk tahun 2050 atau bertanya mengapa satu bulan memiliki 29 hari sementara bulan lainnya 30 hari, inilah proses yang berlangsung di balik layar.

Coba sendiri:

curl "https://api.mabims.dev/api/v1/events?year=2050&calendar=gregorian"

Perhatikan field source dan warnings pada responsnya. Dokumentasi endpoint dan status cakupan data tersedia di mabims.dev/data-sources.

Tanggal Hijriah, Sekarang Offline: Memperkenalkan mabims-hijri

Tue, 01 Sep 2026 00:00:00 GMT

Kalau kamu cuma butuh tanggal Hijriah hari ini di website, REST API sudah cukup. Tinggal fetch, parse JSON, selesai.

Tapi setelah bikin beberapa pakai API itu, saya selalu nemu masalah yang sama:

Setiap load page nge-hit API. Padahal tanggal Hijriah nggak berubah tiap beberapa detik.
Rate limits oke, tapi tetap ada batasnya. Kalau site-mu lagi traffic naik, atau banyak component yang fetch tanggal yang sama…
Offline nggak ada. Bikin PWA atau mobile app? Nggak ada tanggal Hijriah tanpa koneksi internet.
Caching jadi urusanmu. Kamu harus bikin caching layer sendiri, handle data stale, dan tentuin TTL-nya.

Makanya saya bikin mabims-hijri, paket npm offline-first yang bundle data MABIMS 2024-2026 langsung di dalamnya.

Apa yang dilakukan

Bundled MABIMS (2024-2026)  -->  Local cache  -->  Live API (fallback)
     ~70KB, built-in              TTL 24h          only when out of range

Data MABIMS 2024-2026 di-bundle langsung di dalam package (~70KB)
Kalau online, SDK cek /meta buat data yang lebih baru dan auto-sync
Kalau tanggal di luar range bundle, fallback ke live API
Semua operasi today(), convert(), dan range() jalan tanpa internet

Nggak perlu API key. Nggak perlu registrasi. Tinggal npm install.

Quick start

npm install mabims-hijri

import { today, convert } from 'mabims-hijri';

// Tanggal Hijriah hari ini, jalan offline
const date = await today();
console.log(`${date.output.day} ${date.output.month_name} ${date.output.year} H`);

// Konversi tanggal tertentu
const ramadhan = await convert('2026-02-19');
console.log(ramadhan.output.month_name); // 'Ramadhan'

Gitu aja. Nggak perlu base URL, nggak perlu headers, nggak perlu fetch wrapper. Datanya sudah ada di dalam app.

SDK vs REST API: Kapan pakai yang mana?

Saya masih ngerasa REST API itu pilihan yang tepat buat banyak kasus. Ini cara saya membedakannya:

Pakai REST API kalau:

Kamu butuh hilal sky chart (/hilal/viz)
Kamu butuh data di luar 2024-2026 dan nggak mau bundle
Kamu bikin server-side integration di mana kamu manage caching sendiri
Kamu mau pakai OpenAPI spec lengkap dan code generation

Pakai SDK kalau:

Kamu cuma butuh tanggal hari ini, konversi, atau events di app JS/TS
Kamu mau support offline (PWA, mobile app, jaringan nggak stabil)
Kamu mau zero-config, nggak perlu fetch wrapper, nggak perlu caching logic
Kamu capek manage rate limits buat data yang sama

Contohnya, di React app:

import { useState, useEffect } from 'react';
import { today, type HijriDate } from 'mabims-hijri';

function HijriDate() {
  const [date, setDate] = useState<HijriDate | null>(null);

  useEffect(() => {
    today().then((res) => setDate(res.output));
  }, []);

  if (!date) return <span>Loading...</span>;
  return <span>{date.day} {date.month_name} {date.year} H</span>;
}

Nggak perlu manage API URL. Nggak perlu debug loading state. Tinggal import dan pakai.

Isi SDK-nya

Fungsi	Fungsinya
`today()`	Tanggal Hijriah hari ini, timezone-aware
`convert(date)`	Konversi satu tanggal, dua arah
`range(start, end)`	Konversi bulk (maks 45 hari)
`month(year, month)`	Semua hari dalam satu bulan
`year(year)`	Semua hari dalam satu tahun (12 bulan)
`events(year)`	Hari besar Islam (Ramadhan, Idul Fitri, dll.)
`hilal.info(month, year)`	Data visibilitas hilal

Semua ini jalan offline selama tanggal masih di dalam range yang di-bundle.

Catatan untuk React Native

Kalau kamu bikin React Native app, kamu perlu set storage adapter biar caching-nya persisten (pakai @react-native-async-storage/async-storage):

import { setStorageAdapter } from 'mabims-hijri';
import AsyncStorage from '@react-native-async-storage/async-storage';

class RNStorage implements StorageAdapter {
  private prefix = 'mabims_';
  async get(key: string) { return AsyncStorage.getItem(this.prefix + key); }
  async set(key: string, value: string) { await AsyncStorage.setItem(this.prefix + key, value); }
  async has(key: string) { return (await AsyncStorage.getItem(this.prefix + key)) !== null; }
}

setStorageAdapter(new RNStorage());

Tanpa ini, cache reset tiap kali app restart.

Intinya

Kalau kebutuhan Hijriah di app-mu cuma “tampilin tanggal hari ini di header,” jangan bikin caching layer, jangan bikin fetch wrapper, dan jangan pusing soal rate limits.

npm install mabims-hijri

Satu import, satu fungsi, selesai, online atau offline.

Dokumentasi lengkap ada di mabims.dev/sdk. Source code di GitHub: PijarAdiluhung/mabims-hijri.

Kalender Kemenag 2026: Jadwal Lengkap Tanggal Hijriah & Hari Libur

Mon, 31 Aug 2026 00:00:00 GMT

Berikut jadwal lengkap kalender Hijriah tahun 2026 dari Ditjen Bimbingan Masyarakat Islam, Kementerian Agama RI. Kalender ini menjadi acuan utama tanggal-tanggal keagamaan Islam di Indonesia, termasuk hari-hari besar nasional dan cuti bersama. Penentuan awal bulannya menggunakan kriteria MABIMS terbaru: tinggi hilal ≥ 3° dan elongasi ≥ 6,4°.

Tanggal-tanggal Penting Islam 2026

Tanggal Masehi	Peristiwa	Tanggal Hijriah
16 Januari 2026	Isra Mikraj Nabi Muhammad ﷺ	27 Rajab 1447 H
21–22 Maret 2026	Hari Raya Idul Fitri	1–2 Shawwal 1447 H
27 Mei 2026	Hari Raya Idul Adha	10 Dzulhijjah 1447 H
16 Juni 2026	Tahun Baru Islam (1 Muharram)	1 Muharram 1448 H
25 Agustus 2026	Maulid Nabi Muhammad ﷺ	12 Rabiul Awal 1448 H

Kalender Lengkap

Berikut kalender lengkap yang bisa kamu lihat langsung. Klik tombol download untuk menyimpan versi PDF-nya.

Download PDF

Pemetaan Bulan Hijriah – Masehi 2026

Bulan Masehi	Bulan Hijriah
Januari	Rajab – Sya’ban
Februari	Sya’ban – Ramadhan
Maret	Ramadhan – Syawal
April	Syawal – Dzulqa’dah
Mei	Dzulqa’dah – Dzulhijjah
Juni	Dzulhijjah – Muharram
Juli	Muharram – Safar
Agustus	Safar – Rabiul Awal
September	Rabiul Awal – Rabiul Akhir
Oktober	Rabiul Akhir – Jumadil Awal
November	Jumadil Awal – Jumadil Akhir
Desember	Jumadil Akhir – Rajab

Hari Libur Nasional & Cuti Bersama 2026

Tanggal	Keterangan
1 Januari	Tahun Baru 2026 Masehi
16 Januari	Isra Mikraj Nabi Muhammad ﷺ
17 Februari	Tahun Baru Imlek 2577 Kongzili
19 Maret	Hari Suci Nyepi (Tahun Baru Saka 1948)
21–22 Maret	Idul Fitri 1447 H
3 April	Wafat Yesus Kristus
5 April	Kebangkitan Yesus Kristus (Paskah)
1 Mei	Hari Buruh Internasional
14 Mei	Kenaikan Yesus Kristus
27 Mei	Idul Adha 1447 H
31 Mei	Hari Raya Waisak 2570 BE
1 Juni	Hari Lahir Pancasila
16 Juni	Tahun Baru Islam 1448 H
17 Agustus	Proklamasi Kemerdekaan RI
25 Agustus	Maulid Nabi Muhammad ﷺ
25 Desember	Kelahiran Yesus Kristus (Natal)

Cuti bersama: 16, 20, 23, 24 Maret (Idul Fitri) · 18 Maret (Nyepi) · 15 Mei (Kenaikan) · 28–29 Mei (Idul Adha) · 24 Desember (Natal)

Kriteria MABIMS

Penentuan awal bulan Hijriah (1 Ramadhan, 1 Syawal, 1 Dzulhijjah, dll.) didasarkan pada pengamatan hilal (rukyah) yang divalidasi dengan hisab. Negara-negara anggota MABIMS (Brunei Darussalam, Indonesia, Malaysia, dan Singapura) telah menyepakati kriteria visibilitas hilal sebagai berikut. Penjelasan lengkap soal asal-usul dan sejarahnya ada di Apa itu MABIMS?.

Kriteria	Ambang Batas
Ketinggian hilal (altitude)	≥ 3°
Elongasi bulan-matahari	≥ 6,4°

Kedua syarat harus terpenuhi secara bersamaan. Kriteria ini diadopsi sejak 2022, menggantikan kriteria lama “2-3-8” (tinggi ≥ 2°, elongasi ≥ 3°, umur bulan ≥ 8 jam) yang digunakan sejak 1992. Perubahan ini didasarkan pada kompilasi data rukyat global yang menunjukkan bahwa pada posisi hilal rendah dengan elongasi kecil, sabit bulan masih sangat tipis dan sulit diamati secara kasat mata.

Kriteria baru ini merupakan hasil Muzakarah Rukyah dan Takwim Islam MABIMS 2016 di Malaysia, diperkuat oleh Seminar Internasional Fikih Falak di Jakarta (Rekomendasi Jakarta 2017), dan ditandatangani melalui surat bersama ad referendum pada 2021. Pengumuman resmi pemerintah tentang penerapan kriteria ini bisa dilihat di Setkab.

Cek Tanggal Hijriah untuk Tanggal Apa Saja

Mau tahu tanggal 15 Maret 2026 itu tanggal berapa Hijriah? Atau kapan 1 Ramadhan 1448 H dalam kalender Masehi? Cek langsung di kalender Hijriah berbasis kriteria MABIMS kami, atau gunakan API MABIMS.dev (unofficial):

curl "https://api.mabims.dev/api/v1/convert?date=2026-03-15&calendar=gregorian"

{
  "input": { "date": "2026-03-15", "calendar": "gregorian", "tz": null },
  "output": { "date": "1447-06-14", "calendar": "hijri", "day": 14, "month": 6, "month_name": "Sya'ban", "year": 1447, "weekday": "Ahad" },
  "source": "mabims",
  "warnings": []
}

Data berasal dari kalender resmi Kemenag RI yang tersedia publik.

Dokumentasi lengkap: mabims.dev/quickstart

Cara Menampilkan Tanggal Hijriah Kriteria MABIMS

Sun, 30 Aug 2026 00:00:00 GMT

Mau nampilin tanggal Hijriah hari ini di website? Misalnya di header, footer, atau widget masjid/pesantren? Ini cara paling gampang, pakai API gratis mabims.dev, tanpa API key, dan datanya sesuai kriteria MABIMS/Kemenag (bukan Umm al-Qura yang sering beda 1 hari).

Cukup panggil endpoint ini:

GET https://api.mabims.dev/api/v1/today

Responsnya JSON kayak gini:

{
  "input": { "date": "2026-08-24", "calendar": "gregorian", "tz": "Asia/Jakarta" },
  "output": {
    "date": "1448-03-11",
    "calendar": "hijri",
    "day": 11,
    "month": 3,
    "month_name": "Rabiul Akhir",
    "year": 1448,
    "weekday": "Senin"
  },
  "source": "mabims",
  "warnings": []
}

Yang kamu butuhin cuma bagian output, udah ada day, month_name, dan year terpisah, jadi nggak perlu parsing string tanggal sendiri.

Opsi 1: JavaScript (Vanilla, Tanpa Framework)

Paling universal. Tinggal taruh di HTML manapun.

<span id="tanggal-hijriah">Memuat...</span>

<script>
  fetch('https://api.mabims.dev/api/v1/today')
    .then(res => res.json())
    .then(data => {
      document.getElementById('tanggal-hijriah').textContent = data.output.date + ' H'
    })
    .catch(() => {
      document.getElementById('tanggal-hijriah').textContent = '-'
    })
</script>

Selesai. Elemen <span> itu bakal otomatis keisi tanggal Hijriah hari ini, misalnya 1448-03-14 H.

Kalau mau format lebih rapi (nama bulan, bukan angka), kamu nggak perlu mapping manual karena response-nya udah nyediain day, month_name, dan year langsung, jadi tinggal dipakai:

fetch('https://api.mabims.dev/api/v1/today')
  .then(res => res.json())
  .then(data => {
    const { day, month_name, year } = data.output
    document.getElementById('tanggal-hijriah').textContent =
      `${day} ${month_name} ${year} H`
  })
  .catch(() => {
    document.getElementById('tanggal-hijriah').textContent = '-'
  })

Hasilnya jadi: 14 Rabiul Awal 1448 H. Gak perlu parsing string atau bikin array nama bulan sendiri. Ini beda dari kebanyakan API kalender Hijriah lain yang biasanya cuma ngasih tanggal mentah dan bikin kamu harus mapping nama bulan sendiri.

Opsi 2: PHP

Buat website berbasis PHP (custom, atau CMS lawas), pakai file_get_contents atau curl:

<?php
$response = file_get_contents('https://api.mabims.dev/api/v1/today');
$data = json_decode($response, true);
$tanggalHijriah = $data['output']['date'] ?? '-';
?>

<span><?= htmlspecialchars($tanggalHijriah) ?> H</span>

Mau format nama bulan (bukan angka)? Response-nya udah nyediain day, month_name, year langsung, jadi nggak perlu mapping manual:

<?php
$output = $data['output'] ?? [];
$tanggalHijriah = isset($output['day'])
    ? "{$output['day']} {$output['month_name']} {$output['year']} H"
    : '-';
?>

<span><?= htmlspecialchars($tanggalHijriah) ?></span>

Kalau server kamu matiin allow_url_fopen, pakai cURL sebagai gantinya:

<?php
$ch = curl_init('https://api.mabims.dev/api/v1/today');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_TIMEOUT, 5);
$response = curl_exec($ch);
curl_close($ch);

$data = json_decode($response, true);
$tanggalHijriah = $data['output']['date'] ?? '-';
?>

Tips: karena ini request server-side yang blocking, sebaiknya di-cache (misal pakai file cache 1 jam) supaya nggak manggil API setiap kali halaman di-load oleh visitor.

<?php
$cacheFile = __DIR__ . '/hijriah-cache.json';
$cacheTime = 3600; // 1 jam

if (file_exists($cacheFile) && (time() - filemtime($cacheFile) < $cacheTime)) {
    $data = json_decode(file_get_contents($cacheFile), true);
} else {
    $response = file_get_contents('https://api.mabims.dev/api/v1/today');
    $data = json_decode($response, true);
    file_put_contents($cacheFile, $response);
}

$tanggalHijriah = $data['output']['date'] ?? '-';

Opsi 3: WordPress (Shortcode)

Kalau website kamu WordPress, tinggal tambahkan ini ke functions.php tema (atau plugin custom):

function tampilkan_tanggal_hijriah() {
    $cache = get_transient('tanggal_hijriah_hari_ini');
    if ($cache !== false) {
        return $cache;
    }

    $response = wp_remote_get('https://api.mabims.dev/api/v1/today');
    if (is_wp_error($response)) {
        return '-';
    }

    $body = json_decode(wp_remote_retrieve_body($response), true);
    $tanggal = $body['output']['date'] ?? '-';
    $hasil = esc_html($tanggal) . ' H';

    set_transient('tanggal_hijriah_hari_ini', $hasil, HOUR_IN_SECONDS);
    return $hasil;
}
add_shortcode('tanggal_hijriah', 'tampilkan_tanggal_hijriah');

Lalu pakai shortcode [tanggal_hijriah] di halaman, widget teks, atau editor blok manapun. WordPress otomatis handle request-nya lewat wp_remote_get (lebih aman daripada file_get_contents langsung), dan set_transient bikin hasilnya ke-cache 1 jam biar nggak manggil API tiap page load.

Bonus: Nampilin Kalender Sebulan Penuh (Bukan Cuma Hari Ini)

Script nggak pengin nulis kode? Lihat langsung kalender Hijriah MABIMS online di mabims.dev.

Kalau kamu bukan cuma butuh tanggal hari ini, tapi mau bikin grid kalender bulanan (misalnya widget kalender Hijriah lengkap 29-30 hari), pakai endpoint /month:

GET https://api.mabims.dev/api/v1/month?year={Y}&month={M}&calendar=hijri

Contoh, ambil bulan Ramadhan 1447 H:

GET https://api.mabims.dev/api/v1/month?year=1447&month=9&calendar=hijri

Setiap item dalam responsnya berisi pasangan tanggal Gregorian-Hijriah, jadi tinggal di-loop buat bikin grid:

fetch('https://api.mabims.dev/api/v1/month?year=1447&month=9&calendar=hijri')
  .then(res => res.json())
  .then(data => {
    const listEl = document.getElementById('kalender-bulan')
    data.items.forEach(item => {
      const li = document.createElement('li')
      li.textContent = `${item.hijri} (${item.gregorian})`
      listEl.appendChild(li)
    })
  })

Parameter penting:

year & month — wajib. month itu 1–12.
calendar — default hijri. Set gregorian kalau year/month yang kamu kasih itu tahun/bulan Masehi, bukan Hijriah.

Bulan Hijriah yang di luar cakupan tabel resmi (misalnya jauh ke tahun-tahun mendatang) tetap dilayani otomatis lewat perhitungan Neo MABIMS, selama masih dalam rentang yang didukung, jadi gak perlu penanganan khusus di sisi kamu deh.

Butuh Satu Tahun Penuh Sekaligus?

Daripada manggil /month 12 kali buat bikin kalender tahunan, ada endpoint /year yang langsung ngasih semua bulan sekaligus:

GET https://api.mabims.dev/api/v1/year?year=1447&calendar=hijri

Respons-nya dikelompokkan per bulan (key "1" sampai "12"), masing-masing berisi array hari dengan format sama seperti /month:

{
  "input": { "year": 1447, "calendar": "hijri" },
  "count": 354,
  "months": {
    "1": [
      { "gregorian": "2025-06-27", "hijri": "1447-01-01", "weekday": "Jumat", "source": "mabims" }
    ],
    "2": [ "..." ]
  },
  "warnings": []
}

Cocok kalau kamu mau bikin halaman kalender tahunan sekali fetch, tanpa harus request berkali-kali per bulan.

Bahasa/Framework Lain?

Prinsipnya sama di semua bahasa: Cukup HTTP GET ke https://api.mabims.dev/api/v1/today, parse JSON, ambil output.date.

Dokumentasi lengkap endpoint lain (konversi tanggal, kalender bulanan, hari besar Islam) ada di mabims.dev/quickstart.

Di Mana Cari Hilal?

Sat, 29 Aug 2026 00:00:00 GMT

Salah satu endpoint yang paling saya suka di mabims.dev bukan /today atau /convert, tapi /hilal/viz. Endpoint ini generate PNG 720×1280 yang nampilin visualisasi langit senja lengkap dengan posisi bulan, status kelolosan kriteria MABIMS, sampai grafik langit dengan bintang-bintang segala.

Nggak ada API kalender Hijriah lain (setidaknya yang saya temukan) yang punya fitur ini. Jadi tulisan ini bahas gimana cara kerjanya, dari astronomi sampai render pixel.

Di Mana Cari Hilal?

Nah ini pertanyaan yang sering muncul: Di mana kita mengevaluasi kriteria hilal Neo MABMIS?

Kriteria Neo MABIMS (ketinggian hilal ≥ 3°, elongasi ≥ 6,4°) itu namanya juga kriteria rukyah, ia harus dievaluasi dari suatu titik di permukaan bumi. Dan Indonesia itu luas. Jadi harusnya gak cuma milih satu titik; API ngecek 25 titik pengamatan pesisir dari Sabang sampai Rote, dan kriteria dianggap terpenuhi kalau lolos di satu titik manapun, sama seperti logika rukyah Kemenag: hilal terlihat di wilayah Indonesia, bulan baru dimulai. (Lihat juga Jurnal Astroislamica tentang perspektif Maqāṣid al-Syarī’ah terhadap kriteria ini.)

Pola menariknya: untuk bulan-bulan yang “aman”, hampir selalu titik paling barat yang memutuskan. Semakin barat, matahari terbenam semakin mundur, jadi hilalnya semakin tinggi di atas horizon saat senja. Sabang dan pesisir barat Aceh jadi last chance sekaligus first win. Tapi ada bulan-bulan dengan deklinasi bulan selatan di mana arc selatan (selatan Jawa sampai Nusa Tenggara) yang menang. Data historis 1970–2050 menunjukkan titik-titik Jawa (Ujung Kulon, Pangandaran) ikut memutuskan beberapa bulan. Makanya titik-titik selatan itu ada di daftar, bukan pajangan.

Bila kriteria terpenuhi, API melaporkan titik yang memutuskan lewat field deciding_site di /hilal/info, dan grafiknya menampilkan baris TITIK PENGAMAT.

Alur Kerjanya

Simplifikasi dari implementasi aslinya kira-kira begini:

FUNCTION hilal_viz(month, year):
  sighting = resolve_sighting_evening(year, month)
  ms = sighting_on_date(sighting.evening_date)     # 25 titik, satu panggilan
  chosen = ms.deciding_site or ms.best_site        # titik penentu (atau terdekat)
  alt_ok = chosen.alt_refracted >= 3.0°
  elong_ok = chosen.elongation >= 6.4°
  data = build_chart_data(..., decider=chosen)
  img = render_chart(data)
  return PNG

1. Resolve malam pengamatan

Kalau kamu minta visibilitas untuk bulan Ramadhan, endpoint ini nggak menghitung tanggal 1 Ramadhan itu sendiri, tapi mundur ke malam ke-29 Sya’ban, karena itu malam yang sebenarnya diamati untuk menentukan apakah besok sudah masuk Ramadhan atau belum. Ini logika dasar rukyah: kamu mengamati hilal di ujung bulan berjalan, bukan di awal bulan target.

2. Hitung astronomi malam itu, di titik penentu

Dua kategori data dihitung:

Kriteria — moon_alt (ketinggian bulan toposentris, terkoreksi refraksi), moon_az (azimut), sun_alt, dan elongation (jarak sudut bulan-matahari, geosentris sesuai konvensi hisab Indonesia). Ini angka-angka yang langsung dibandingkan ke ambang batas MABIMS — semuanya milik satu titik yang sama, jadi adegan langit, tabel kriteria, dan verdict nggak bisa saling kontradiksi.
Waktu pengamat (observer-clock) — iluminasi, jam matahari terbenam, dan jam bulan terbenam, semuanya di titik penentu dan ditampilkan dalam zona waktu lokal titik itu (WIB atau WITA).

3. Cek ambang batas Neo MABIMS

alt_ok   = moon_alt_refracted >= 3.0°
elong_ok = elongation         >= 6.4°

Dua syarat ini harus terpenuhi bersamaan, minimal di satu titik. Kalau di titik manapun nggak ada yang lolos, hilal dianggap belum memenuhi kriteria visibilitas, meskipun bulan sudah di atas horizon di beberapa titik.

Contoh Hasil

Screenshot di atas itu visibilitas untuk 1 Dzulqa’dah 1447 H (evaluasi malam 29 Syawal 1447 H, 18 Apr 2026, titik pengamatan Sabang):

Altitude bulan +10.4° (lolos, syarat ≥3.0°)
Elongasi 14.5° (lolos, syarat ≥6.4°)
Iluminasi 1.4% — sabit masih ramping tapi udah jelas
Matahari terbenam 18:46, bulan terbenam 19:31 — selisih 45 menit, jendela pengamatan nyaman

Status: MEMENUHI KRITERIA, dan kali ini marginnya jauh di atas ambang. Bandingin sama bulan-bulan borderline (misal 1446-08 yang lolos dengan margin 0,006°) — di grafiknya sabitnya nyaris nggak kelihatan, dan verdict-nya “MENDEKATI BATAS”. Grafik ini nggak bohong.

Kenapa Repot-repot Bikin Ini?

Karena angka mentah (moon_alt: 10.4, elongation: 14.5) nggak intuitif buat kebanyakan orang, termasuk saya sendiri. Tapi begitu divisualisasikan -> lihat posisi bulan relatif ke horizon, lihat pill hijau/merah, lihat tabel kriteria -> jadi jauh lebih gampang dicerna. Endpoint ini niatnya bukan cuma buat developer yang butuh JSON, tapi juga buat siapa saja yang penasaran “kok bisa sih hilal dibilang terlihat/tidak terlihat” tanpa harus paham astronomi.

Coba sendiri di demo:

GET https://api.mabims.dev/api/v1/hilal/viz?month=1&year=1448

Ganti month dan year sesuai bulan Hijriah yang mau dicek. Dokumentasi lengkap parameter ada di mabims.dev/endpoints/hilal.

Tutorial Integrasi MABIMS API

Fri, 28 Aug 2026 00:00:00 GMT

API ini saya bikin buat developer, dan saya nggak mau integrasinya berhenti di dokumentasi yang isinya cuma GET /today lalu selesai. Jadi di tulisan ini saya mau kasih contoh dari yang paling sederhana sampai yang agak proper: JavaScript biasa, Vue, React, sampai aplikasi mobile.

Paling sederhana: JavaScript

Kalau website kamu cuma butuh menampilkan tanggal Hijriah hari ini, sebenarnya sesimpel ini:

const response = await fetch("https://api.mabims.dev/api/v1/today");
const data = await response.json();

console.log(data);

Response-nya kira-kira begini:

{
  "input": { "date": "2026-08-28", "calendar": "gregorian", "tz": "Asia/Jakarta" },
  "output": { "date": "1448-03-15", "calendar": "hijri", "day": 15, "month": 3, "month_name": "Rabiul Akhir", "year": 1448, "weekday": "Jumat" },
  "source": "mabims",
  "warnings": []
}

Kamu tinggal ambil field output untuk ditampilkan. Sudah lengkap, tidak perlu parse sendiri:

const { day, month_name, year } = data.output;
document.querySelector("#hijri-date").textContent = `${day} ${month_name} ${year} H`;

Jadi misalnya di header website kamu ada:

<div id="hijri-date"></div>

tinggal panggil fungsi tadi dan tanggal Hijriahnya akan muncul.

Nggak perlu install library. Nggak perlu API key. Nggak perlu bikin server sendiri cuma untuk mengambil tanggal Hijriah.

Kalau pakai timezone

Ini bagian yang menurut saya penting.

Tanggal Hijriah bukan cuma soal konversi tanggal Masehi → Hijriah. Timezone juga menentukan “hari ini” itu hari apa.

Misalnya server kamu berada di Amerika, tapi user kamu kebanyakan di Indonesia. Jangan sampai jam 00:30 WIB dianggap masih tanggal sebelumnya karena server kamu masih berada di hari sebelumnya.

mabims.dev menyediakan timezone override supaya kamu bisa menentukan timezone yang ingin digunakan. Pakai parameter tz:

const response = await fetch(
  "https://api.mabims.dev/api/v1/today?tz=Asia/Jakarta"
);

const data = await response.json();

Untuk aplikasi yang memang targetnya Indonesia, saya biasanya akan eksplisit menggunakan Asia/Jakarta, Asia/Makassar, atau Asia/Jayapura sesuai kebutuhan.

Di Vue

Kalau kamu pakai Vue, konsepnya sama. Bedanya cuma kita simpan hasil API ke state.

Misalnya dengan Composition API:

<script setup>
import { ref, onMounted } from "vue";

const hijriDate = ref(null);

onMounted(async () => {
  const response = await fetch(
    "https://api.mabims.dev/api/v1/today?tz=Asia/Jakarta"
  );

  hijriDate.value = await response.json();
});
</script>

<template>
  <div v-if="hijriDate">
    {{ hijriDate.output.date }}
  </div>

  <div v-else>
    Memuat tanggal Hijriah...
  </div>
</template>

Selesai.

Saya justru menyarankan pendekatan seperti ini daripada memasukkan library kalender Hijriah yang ukurannya jauh lebih besar kalau kebutuhan aplikasi kamu cuma menampilkan tanggal Hijriah.

Di React

Di React juga kurang lebih sama:

import { useEffect, useState } from "react";

export default function HijriDate() {
  const [date, setDate] = useState(null);

  useEffect(() => {
    fetch("https://api.mabims.dev/api/v1/today?tz=Asia/Jakarta")
      .then((response) => response.json())
      .then((data) => setDate(data));
  }, []);

  if (!date) {
    return <span>Memuat tanggal Hijriah...</span>;
  }

  return <span>{date.output.date}</span>;
}

Tidak ada dependency tambahan.

React tinggal fetch API → simpan hasilnya → render.

Kalau butuh tanggal tertentu

/today cocok kalau yang kamu butuhkan adalah tanggal Hijriah hari ini.

Tapi bagaimana kalau user memilih tanggal dari date picker?

Misalnya user memilih:

17 Agustus 2026

Kamu bisa menggunakan endpoint konversi:

const response = await fetch(
  "https://api.mabims.dev/api/v1/convert?date=2026-08-17"
);

const data = await response.json();

Ini berguna untuk kalender, form, artikel yang punya tanggal publikasi, atau fitur pencarian tanggal.

Misalnya user memilih tanggal 17 Agustus 2026 dan kamu ingin menampilkan versi Hijriahnya. Tinggal kirim tanggal Gregorian tersebut ke API.

Jangan lupa cek `source`

Ada satu hal yang menurut saya cukup penting ketika mengonsumsi API ini.

Response mabims.dev punya informasi source.

Secara sederhana, ada dua kemungkinan:

mabims — tanggal berasal dari tabel resmi Kemenag yang tersedia.
mabims-computed — tanggal dihitung menggunakan kriteria Neo MABIMS sebagai fallback ketika tanggal tersebut berada di luar cakupan tabel.

Kenapa saya expose informasi ini?

Karena saya nggak mau API diam-diam memberikan hasil perhitungan lalu developer mengira itu adalah tanggal resmi dari Kemenag.

Kalau aplikasi kamu cukup serius soal kalender, kamu bisa menyimpan atau menampilkan informasi tersebut.

if (data.source === "mabims-computed") {
  console.log("Tanggal menggunakan hasil perhitungan Neo MABIMS");
}

Dan kalau API mengembalikan warnings, sebaiknya jangan dibuang begitu saja.

if (data.warnings?.length) {
  console.warn(data.warnings);
}

Kalau aplikasinya mobile

Kalau kamu bikin aplikasi Android/iOS, prinsipnya sebenarnya sama.

Mau Flutter, React Native, Kotlin, Swift, atau framework lainnya, selama aplikasinya bisa melakukan HTTP request, kamu bisa memanggil API ini.

Misalnya pseudocode-nya:

GET https://api.mabims.dev/api/v1/today?tz=Asia/Jakarta
        ↓
JSON response
        ↓
Simpan ke state
        ↓
Tampilkan:
"1448-03-15"

API-nya tidak peduli apakah request datang dari browser, server, atau aplikasi mobile.

Tapi apakah setiap halaman harus request ke API?

Nah, ini yang mulai masuk ke urusan arsitektur.

Kalau website kamu punya 100 komponen yang semuanya membutuhkan tanggal Hijriah, jangan setiap komponen melakukan fetch("/today") sendiri-sendiri.

Lebih baik fetch sekali, kemudian hasilnya dipakai bersama.

Di frontend kamu bisa bikin composable/hook/service sendiri.

Misalnya di React:

export async function getHijriToday() {
  const response = await fetch(
    "https://api.mabims.dev/api/v1/today?tz=Asia/Jakarta"
  );

  if (!response.ok) {
    throw new Error("Gagal mengambil tanggal Hijriah");
  }

  return response.json();
}

Kemudian komponen-komponen lain tinggal menggunakan fungsi tersebut.

Untuk aplikasi yang lebih besar, bahkan bisa kamu cache hasilnya karena tanggal Hijriah tidak berubah setiap beberapa detik.

Kalau pakai SSR atau backend?

Ini malah lebih menarik.

Kalau kamu menggunakan Next.js, Nuxt, Laravel, Rails, Django, atau backend lainnya, kamu juga bisa memanggil mabims.dev dari server kamu.

Contohnya secara sederhana:

const response = await fetch(
  "https://api.mabims.dev/api/v1/today?tz=Asia/Jakarta"
);

const hijriDate = await response.json();

Kemudian server kamu yang mengirimkan tanggal tersebut ke browser.

Keuntungannya, tanggal Hijriah bisa sudah tersedia ketika halaman pertama kali dirender.

Tapi kalau kamu melakukan ini, tetap pikirkan caching. Tidak ada gunanya server kamu request tanggal yang sama berkali-kali dalam sehari.

Jadi kapan sebaiknya pakai API ini?

Menurut saya, kalau kebutuhanmu cuma:

“Saya ingin menampilkan tanggal Hijriah di website saya.”

Jangan bikin sistem kalender sendiri.

Jangan maintain tabel sendiri.

Jangan copy-paste tanggal dari kalender PDF ke database.

Dan jangan berharap library kalender yang default-nya Umm al-Qura otomatis cocok untuk kebutuhan Indonesia.

Cukup:

Website / App
      ↓
mabims.dev
      ↓
Tanggal Hijriah berbasis MABIMS

Kalau butuh tanggal hari ini, pakai /today.

Kalau butuh konversi tanggal tertentu, pakai /convert.

Kalau aplikasinya butuh timezone tertentu, tentukan timezone-nya secara eksplisit.

Dan kalau aplikasimu penting secara administratif atau keagamaan, tetap perlakukan API sebagai sumber data teknis, bukan pengganti keputusan resmi Kemenag.

Sekian. Semoga bermanfaat!

Cerita di Balik MABIMS API

Thu, 27 Aug 2026 00:00:00 GMT

Ada cerita lucu (dan sedikit menyedihkan) di balik mabims.dev.

Dulu, website Kemenag pernah menampilkan tanggal Hijriah di halamannya. Banyak orang termasuk saya sendiri terbiasa mengandalkannya. Tinggal buka website, lihat pojok atas, jadi tahu deh sekarang tanggal berapa Hijriah.

Sampai suatu hari, ada postingan viral. Kalender keluaran Kemenag bilang tanggal 30, tapi website Kemenag bilang udah masuk tanggal 1 bulan berikutnya. Selisih sehari.

Postingan itu itu nyebar. Rame. Orang-orang mempertanyakan kenapa situs resmi bisa beda sama kalendernya yang dikeluarkan sendiri.

Solusinya? Dihapus aja

Saat itu saya nggak tahu detail di baliknya, apakah itu bug, salah kalkulasi, atau apa. Yang saya tahu, ujung-ujungnya elegan sekali: tanggal Hijriah di website itu dihapus. Bukan diperbaiki, dihapus. Masalah selesai sih iya… tapi kayak gimana gitu.

Beberapa tahun kemudian, saya jadi junior dev

Waktu saya mulai kerja sebagai developer, saya baru ngerti apa yang mungkin terjadi. Kalau mau nampilin kalender Hijriah di web, cara paling gampang ya tinggal pasang library atau panggil API pihak ketiga. Dan hampir semua library/API kalender Hijriah yang gampang ditemukan itu defaultnya pakai kriteria Umm al-Qura, kalender resmi Arab Saudi.

Masuk akal kalau itu yang dipakai. Dokumentasinya lengkap, gampang diintegrasikan, gratis. Tapi Umm al-Qura itu dirancang untuk kebutuhan Arab Saudi, bukan hasil rukyah atau sidang isbat Kemenag RI. Makanya bisa beda ±1 hari dari yang diumumkan di Indonesia, persis kejadian yang bikin viral itu.

Jadi kemungkinan besar itu bukan “bug” dalam arti kesalahan kode. Itu bug karena pakai sumber data yang salah untuk konteks Indonesia.

Isi gap-nya

Setelah nyadar itu, saya mikir: kalau developer lain di Indonesia mau bikin aplikasi yang nampilin kalender Hijriah dan pengen datanya sesuai keputusan Kemenag (bukan Saudi), opsinya dikit banget. Kebanyakan harus scraping manual atau maintain tabel sendiri (spoiler: developer =/= ahli astronomi).

Makanya saya bikin mabims.dev: API kalender Hijriah yang sumbernya dari kalender resmi Kemenag RI, pakai kriteria Neo MABIMS untuk fallback di luar cakupan. Gratis, tanpa API key, tinggal panggil endpoint.

Realistisnya… saya nggak tahu bakal banyak yang pakai atau nggak. Tapi minimal ada satu aplikasi yang pasti pakai: kajian.malangmengaji.com, yang saya bangun juga. Kalau nggak ada developer lain yang butuh, ya sudah… API ini akan tetap jalan buat aplikasi saya sendiri.

Tapi kalau kamu develop aplikasi yang butuh kalender Hijriah yang akurat buat Indonesia, silakan pakai. Gratis, open source, dan mudah-mudahan nggak akan pernah perlu dihapus karena ketauan salah tanggal :)

Coba sekarang:

curl "https://api.mabims.dev/api/v1/today"

Dokumentasi lengkap ada di mabims.dev/quickstart. Bukan developer? Coba dulu di browser: kalender Hijriah MABIMS.

API Kalender MABIMS | Blog

Kenapa Tanggal Hijriah Berganti Saat Maghrib (dan Cara Menanganinya)

Kenapa hari Hijriah dimulai saat maghrib?

Contoh yang paling gampang: malam pertama Ramadan

Masalahnya buat developer

Solusinya: next=true

Satu hal penting: API nggak menghitung waktu maghrib

Contoh implementasi JavaScript

Bagaimana kalau lewat tengah malam?

Timezone dan maghrib itu satu paket

Jangan lupa cek next.source

Soal cache

Error yang mungkin muncul

Ringkasan

Cara Integrasi MABIMS API ke Aplikasi iOS & Android

Kenapa Harus MABIMS (Bukan Umm al-Qura)?

Arsitektur 2 Layer

Kapan Refresh Cache /year?

Contoh Kode: Swift (iOS)

Contoh Kode: Kotlin (Android)

Edge Case yang Wajib Dipikirin

Bonus: Pakai React Native/Expo?

Penutup

Visibilitas Hilal Rabiul Akhir 1448 H

Melihat petanya dulu

Lalu, apa yang terjadi di langit?

Kesimpulan

Bedah mabims-computed: Apa yang Terjadi di Balik Layar?

Dua jenis data, satu API

Neo MABIMS dalam dua angka

Dari hilal ke panjang bulan

Bukan konversi aritmetika biasa

Bisa berjalan mundur juga

Bagian yang membuat saya harus menyelidiki ulang

Kondisi borderline itu nyata

Kapan mabims-computed boleh digunakan?

Intinya

Tanggal Hijriah, Sekarang Offline: Memperkenalkan mabims-hijri

Apa yang dilakukan

Quick start

SDK vs REST API: Kapan pakai yang mana?

Isi SDK-nya

Catatan untuk React Native

Intinya

Kalender Kemenag 2026: Jadwal Lengkap Tanggal Hijriah & Hari Libur

Tanggal-tanggal Penting Islam 2026

Kalender Lengkap

Pemetaan Bulan Hijriah – Masehi 2026

Hari Libur Nasional & Cuti Bersama 2026

Kriteria MABIMS

Cek Tanggal Hijriah untuk Tanggal Apa Saja

Cara Menampilkan Tanggal Hijriah Kriteria MABIMS

Opsi 1: JavaScript (Vanilla, Tanpa Framework)

Opsi 2: PHP

Opsi 3: WordPress (Shortcode)

Bonus: Nampilin Kalender Sebulan Penuh (Bukan Cuma Hari Ini)

Butuh Satu Tahun Penuh Sekaligus?

Bahasa/Framework Lain?

Di Mana Cari Hilal?

Di Mana Cari Hilal?

Alur Kerjanya

1. Resolve malam pengamatan

2. Hitung astronomi malam itu, di titik penentu

3. Cek ambang batas Neo MABIMS

Contoh Hasil

Kenapa Repot-repot Bikin Ini?

Tutorial Integrasi MABIMS API

Paling sederhana: JavaScript

Kalau pakai timezone

Di Vue

Di React

Kalau butuh tanggal tertentu

Jangan lupa cek source

Kalau aplikasinya mobile

Tapi apakah setiap halaman harus request ke API?

Kalau pakai SSR atau backend?

Jadi kapan sebaiknya pakai API ini?

Cerita di Balik MABIMS API

Solusinya? Dihapus aja

Beberapa tahun kemudian, saya jadi junior dev

Solusinya: `next=true`

Jangan lupa cek `next.source`

Kapan Refresh Cache `/year`?

Kapan `mabims-computed` boleh digunakan?

Jangan lupa cek `source`