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:
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. :)
Top comments (0)