DEV Community: Pijar Sukma Adiluhung

How a niche calendar page got to #1 on Google and Bing

Pijar Sukma Adiluhung — Mon, 21 Sep 2026 06:55:03 +0000

I maintain mabims.dev, a free, open-source Hijri calendar API for Indonesia. Its calendar page, Kalender Hijriah MABIMS, now ranks #1 on Google and Bing for "kalender hijriah mabims" (screenshots below, taken 21 Sep 2026).

Some context first. It's a niche, low-competition query, rankings vary by location, and I can't prove which change moved the needle. This is what the page does today.

Real HTML on every request

The page started as a static build. It's now rendered on the server, in a Node container separate from the API. The file opts out of prerendering with export const prerender = false;, and on each request it fetches from the API over the internal network:

const apiBase = import.meta.env.INTERNAL_API_BASE ?? 'http://localhost:8000';
const res = await fetch(`${apiBase}/api/v1/month?year=${currentYear}&month=${currentMonth}&calendar=hijri`);

The month grid, today's date, important dates, a 12-month summary, and the hilal facts are all in the first HTML response. The browser script only handles month navigation and refreshes. The browser uses the public API base, and the server uses the internal one.

Fresh, but cheap: cache until midnight Jakarta

Rendering on every hit would be wasteful, and a daily static build goes stale. So the page sets its own cache header, expiring at midnight in Jakarta, the same rhythm as the API's /today:

const ttl = 86400 - secsOfDayInJakarta;
Astro.response.headers.set('Cache-Control', `public, max-age=0, s-maxage=${ttl}`);

The CDN (Bunny) can hold the page until then, so the origin should render at most once per region per day. The header is only set when the /today fetch succeeded, so a failed render isn't cached for the day.

What's in the HTML

A real table for the year. A 12-month overview with <th scope="row"> for each month, its Gregorian date range, and its length in days.
Text generated from data. The hilal section builds a sentence like "Kapan Jumadil Awal dimulai? Berdasarkan kriteria Neo MABIMS…", followed by the actual numbers: moon altitude, elongation, illumination, moon age, sunset and moonset.
Images with descriptive alt text, lazy-loaded, with width and height set.
Important dates as <article> rows, not a JS-only widget.

One source for the FAQ and its schema

The visible FAQ and the FAQPage JSON-LD come from the same array:

acceptedAnswer: { '@type': 'Answer', text: f.aPlain ?? f.a }

Answers with links or <code> have aHtml for display and aPlain for the schema. One question, the date of 1 Ramadhan, is built from live event data.

The title comes from data

const title = `Kalender Hijriah MABIMS ${currentYear} (${masehiYear}) • Kriteria Kemenag Neo MABIMS`;

The target phrase is first, the years roll over automatically, and there's an explicit canonical. Google still shows my old title, "Kalender Hijriah 1448 H & 2026", while Bing shows the new one. That's recrawl lag, so I requested reindexing in Search Console.

Say what you are

The page says in several places that it's independent, not affiliated with Kemenag, and that results are estimates. The FAQ also explains why Google Calendar (Umm al-Qura) can differ by a day. For a topic people take seriously, I think that honesty builds trust, and it answers questions people are already searching.

What I'd still fix

Midnight vs maghrib. The cache expires at midnight, but the Hijri date changes at maghrib.
The month grid is divs, not a semantic table.
No Event schema or <time> tags for the holidays, though the data is there.
The H1 is followed by only a date line. The explanatory text sits lower, in the "Tentang" section.

Beyond the page

I also published posts on dev.to, Medium, and Kompasiana, and the GitHub READMEs link to the page with descriptive anchors.

If you've ranked a data or tool page, I'd like to hear what mattered most for you.

Peace!

Indonesians! Your Hijri Calendar Widget Shouldn't Need a Network Call. So I Fixed That.

Pijar Sukma Adiluhung — Tue, 01 Sep 2026 02:38:33 +0000

A while back I wrote about building mabims.dev, a free open-source API for Indonesia's Hijri calendar based on MABIMS criteria (not Umm al-Qura, which is what most Hijri libraries default to and which can be off by a day from what's officially observed here).

But an API is still an API... every time your widget renders, you're firing a network request just to answer "what's today's Hijri date?" For something that changes once a day and barely ever needs live computation, that felt like overkill.

So I built mabims-hijri, an npm package that bundles the calendar data directly into your app. Most lookups resolve instantly, with zero network calls.

The Idea

Hijri dates for 2024–2026 are already known, they're not live-computed, they come from an official curated table. So instead of hitting an API for a fact that doesn't change, the package ships that table (~72KB of JSON) right inside itself.

npm install mabims-hijri

import { today } from 'mabims-hijri'

const date = await today()
console.log(date.output)
// {
//   date: '1448-03-18',
//   calendar: 'hijri',
//   day: 18,
//   month: 3,
//   month_name: 'Rabiul Awal',
//   year: 1448
// }

That call resolves from bundled data. No fetch, no waiting, works offline.

Three-Tier Fallback

For dates outside the bundled range (post-2026), it falls back gracefully instead of just failing:

┌───────────────────┐     ┌──────────────────┐     ┌───────────────────┐
│  Bundled MABIMS    │ ──► │  In-Memory Cache │ ──► │  Live API         │
│  (data.json)       │     │  (per-session)    │     │  (mabims.dev)     │
└───────────────────┘     └──────────────────┘     └───────────────────┘
      Built-in                 Always fast            Fallback only
      2024–2026                (TTL: 24h)             (outside range)

Bundled data: instant, no network, covers 2024-01-13 to 2026-12-31.
In-memory cache: anything fetched from the API gets cached for 24h so repeat lookups stay fast.
Live API: only touched when you ask for a date outside the bundled range.

The package also silently checks once a day for a newer version of the table and updates itself in the background, so it stays current without you having to bump the package version by hand.

Converting Dates

Same offline-first behavior applies to conversion, not just "today":

import { convert } from 'mabims-hijri'

// Gregorian → Hijri
const hijri = await convert('2026-08-31')
console.log(hijri.output.month_name) // 'Rabiul Awal'

// Hijri → Gregorian
const gregorian = await convert('1448-03-18', 'hijri')

Rendering a Widget (React example)

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

function HijriToday() {
  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>
}

First render, no spinner needed in practice! The bundled lookup is fast enough that useEffect resolves almost immediately.

Works Anywhere `fetch` Exists

Node 18+, browsers, edge runtimes (Cloudflare Workers, Vercel Edge, Deno), and React Native. For React Native, there's no localStorage, so persistent caching needs a storage adapter... but good news! The package exposes a simple interface for that:

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

setStorageAdapter({
  get: (key) => AsyncStorage.getItem('mabims_' + key),
  set: (key, value) => AsyncStorage.setItem('mabims_' + key, value),
  has: async (key) => (await AsyncStorage.getItem('mabims_' + key)) !== null,
})

Without it, caching just falls back to in-memory (works fine, just doesn't persist across app restarts).

Other Things It Covers

Beyond today() and convert(), the package wraps the full API surface: range() for bulk date conversion, month()/year() for rendering calendar grids, events() for Islamic holidays (Ramadan, Idul Fitri, Idul Adha, etc.), and hilal.info() for moon-visibility data used to determine the start of a Hijri month. Full reference is in the README.

Try It

npm install mabims-hijri

npm: npmjs.com/package/mabims-hijri
Source: github.com/PijarAdiluhung/mabims-hijri
API docs: mabims.dev

MIT licensed, zero dependencies beyond native fetch. If you build something with it or hit an edge case, issues and PRs are welcome.

Hijri Dates in Indonesia Were a Pain to Get Right. Not Anymore.

Pijar Sukma Adiluhung — Sun, 30 Aug 2026 11:20:06 +0000

If you've ever built a website for Indonesian users and needed to show today's Hijri date, you probably know the pain. Most Hijri calendar APIs and libraries default to Umm al-Qura (Saudi Arabia's calendar), which can differ by a full day from what's actually observed and announced in Indonesia.

It's not just a theoretical mismatch. In my own community, this got bad enough that nobody trusts online Hijri dates anymore. People just wait for the official government announcement instead of checking a website or app, because too many times, the date shown online didn't match what Kemenag (Indonesia's Ministry of Religious Affairs) actually announced. A one-day difference sounds small, until it's the difference between fasting on the right day or not.

The root cause is simple: Indonesia (along with Malaysia, Brunei, and Singapore) uses a different visibility standard called MABIMS, not Umm al-Qura. Most APIs just never bothered to support it.

That's exactly the gap I set out to close: mabims.dev an open-source Hijri calendar API for Indonesia, built on the country's official MABIMS criteria instead of Saudi Arabia's Umm al-Qura standard. Free, open-source, no API key required. Here's how to use it.

What We're Building

A simple "Today in Hijri" widget, then leveling it up into a date converter and a full month grid. All plain JavaScript, no dependencies.

Step 1: Get Today's Date

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

Response:

{
  "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
  },
  "source": "mabims",
  "warnings": []
}

Note the output object already gives you day, month_name, and year separately — no string parsing needed.

Step 2: Render It

<span id="hijri-date">Loading...</span>

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

That's it. Output: 11 Rabiul Akhir 1448 H.

Step 3: Add a Date Converter

Sometimes you need to convert a specific date, not just "today." Use /convert:

GET https://api.mabims.dev/api/v1/convert?date=2026-08-24&calendar=gregorian

async function convertDate(date) {
  const res = await fetch(`https://api.mabims.dev/api/v1/convert?date=${date}&calendar=gregorian`)
  const data = await res.json()
  return data.output
}

convertDate('2026-08-24').then(output => {
  console.log(`${output.day} ${output.month_name} ${output.year} H`)
})

Flip calendar=gregorian to calendar=hijri (with a Hijri-format date like 1448-03-11) to convert the other direction.

Step 4: Render a Full Month Grid

Need a whole calendar, not just one date? Use /month:

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

fetch('https://api.mabims.dev/api/v1/month?year=1447&month=9&calendar=hijri')
  .then(res => res.json())
  .then(data => {
    data.items.forEach(item => {
      console.log(`${item.hijri} — ${item.gregorian}`)
    })
  })

Need a whole year in one call instead of looping /month twelve times? There's a /year endpoint too, grouped by month.

What's Under the Hood

mabims.dev sources its dates from Kemenag RI's official tables (2024–2026 currently), and falls back to computed Neo MABIMS criteria (moon altitude ≥ 3°, elongation ≥ 6.4°) for dates outside that range, up to 2053. Every response tells you which one you got via the source field: "mabims" for table data, "mabims-computed" for the calculated fallback.

There's also a genuinely fun endpoint, /hilal/viz, that renders an actual sky chart PNG showing moon position, visibility criteria, and verdict for any given month — worth a look if you're curious how moon-sighting criteria translate visually.

Try It / Contribute

Docs: mabims.dev
Source: github.com/PijarAdiluhung/mabims-api

No API key, no rate-limit paywall, CORS-open so you can call it straight from the browser. If you build something with it, or hit an edge case, issues and PRs are welcome.

I Built an API Because My Government’s Website Got the Date Wrong (and Just… Deleted It)

Pijar Sukma Adiluhung — Sat, 29 Aug 2026 03:26:27 +0000

There’s a funny (and slightly sad) story behind why I built mabims.dev.

It started with a date.

More specifically, a Hijri date.

Once Upon a Time, the Government Website Had the Date

For a long time, Indonesia’s Ministry of Religious Affairs (Kemenag) website displayed the current Hijri date.

It was convenient.

You opened the website, looked at the corner of the page, and there it was:

Today: 30 Sha'ban

Simple enough.

A lot of people, including me, got used to relying on it.

Then one day, something weird happened.

A post went viral.

Someone noticed that the official calendar published by Kemenag said one date, while the date displayed on Kemenag’s own website said the next day.

They were off by one day.

People started asking:

How can the official website and the official calendar disagree with each other?

The post spread.

People discussed it.

And then…

The Solution? Just Delete It.

I didn't know what exactly happened behind the scenes.

Maybe it was a bug.

Maybe it was a calculation issue.

Maybe the website was using a different data source.

I don't know.

But I do remember what happened eventually.

The Hijri date disappeared from the website.

Problem solved.

Technically.

If you can't display the wrong date, you can't display a wrong date.

Elegant. 😂

At the time, I just thought it was funny.

A few years later, I became a developer.

And suddenly, the story made a lot more sense.

Years Later, I Became a Junior Developer

Once I started working as a developer, I learned how easy it is to add a Hijri date to a website.

You don't need to calculate the lunar calendar yourself.

You just install a library.

Or call an API.

There are plenty of them.

The problem is that most of the libraries and APIs you'll find use Umm al-Qura by default.

And that's perfectly reasonable.

Umm al-Qura is the official calendar of Saudi Arabia. It's well documented, widely supported, and easy to integrate.

For a developer who just wants:

Gregorian date → Hijri date

it works great.

But there's a catch.

Indonesia doesn't use the Saudi calendar as its official reference.

The Indonesian context involves Kemenag's calendar, astronomical calculations, and the Neo MABIMS criteria.

As a result, the Hijri date can differ by one day.

And suddenly that old story made sense.

Maybe the problem wasn't really:

"The code is wrong."

Maybe it was:

"The code is using the wrong source of truth for the context."

That's a very different problem.

So I Looked for an Indonesian-Friendly API

I started thinking about a fairly simple question:

If I'm an Indonesian developer and I want to display the Hijri date according to Kemenag, what do I use?

The answer wasn't particularly satisfying.

I could:

Scrape Kemenag's website.
Maintain my own calendar table.
Find some obscure data source.
Calculate everything myself.
Or just use a normal Hijri API and accept that it might be a day off.

None of those felt particularly great.

And option #4 is especially dangerous.

Because the application will happily tell users:

1 Ramadan

while the official Indonesian calendar says:

30 Sha'ban

Your code isn't crashing.

Your API isn't returning an error.

Your tests might all pass.

Everything looks fine.

The date is just… wrong.

So I Built One

That's why I built mabims.dev.

It's a Hijri calendar API designed specifically for the Indonesian context.

The primary source is the official Kemenag RI calendar, with Neo MABIMS criteria used as a fallback outside the available official data range.

The goal is deliberately simple:

Your application
       ↓
   mabims.dev
       ↓
Kemenag / Neo MABIMS
       ↓
Indonesian Hijri date

No API key.

No complicated authentication.

No scraping required on the developer's side.

Just call an endpoint.

For example:

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

And you get the current Hijri date according to the project's Indonesian calendar reference.

Why Not Just Use Umm al-Qura?

To be clear: Umm al-Qura isn't bad.

It's a perfectly legitimate calendar system.

If you're building something for Saudi Arabia, or your application specifically needs Umm al-Qura, use it.

The problem is assuming that:

"Hijri calendar = one universal calendar."

It isn't quite that simple.

Different countries and institutions can use different methodologies, observations, calculations, and official decisions.

And when you're building software that deals with religious dates, a difference of one day isn't necessarily a minor UI issue.

It can affect:

Ramadan
Eid
fasting schedules
Islamic events
religious announcements
prayer-related applications
educational content
community calendars

For an Indonesian application, the Indonesian source of truth matters.

I'm Not an Astronomer

There's another reason I wanted to build this as an API.

Developers shouldn't have to become astronomers just to display a calendar.

If an application needs the Indonesian Hijri date, the developer should be able to write something like:

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

and move on with building the actual application.

The complicated part: calendar data, methodology, historical coverage, and fallback logic, belongs behind the API.

That's what APIs are good at.

Will Anyone Actually Use It?

Honestly?

I have no idea.

Maybe nobody will.

But at least one application already uses it:

kajian.malangmengaji.com, which I also built.

So even if nobody else ever uses the API, it still solves a real problem for one of my own projects.

And that's good enough reason for me.

If other Indonesian developers find it useful, even better.

It's Free and Open Source

I wanted the barrier to adoption to be as low as possible.

So:

Free to use
No API key
Open source
Simple HTTP API
Designed around the Indonesian context

You can try it right now:

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

The full documentation is available at:

https://mabims.dev/quickstart

The Real Lesson

The funny thing about this project is that it didn't start with:

"I'm going to build a Hijri calendar API."

It started with:

"Why is the official website showing the wrong date?"

Then years later, after becoming a developer, I realized that the problem wasn't necessarily a broken algorithm.

Sometimes software can be perfectly correct and still produce the wrong answer.

Because the source of truth is wrong.

That's a lesson I keep finding useful in software engineering:

Correct code + wrong assumptions = wrong software.

And sometimes, instead of deleting the feature…

you just need to build a better API.

Hopefully, this one won't have to be deleted because it got the date wrong. :)