Ask a teacher in Kathmandu when the second-term exams start, and the answer will come in Bikram Sambat. Ask when the school was founded, and that date is BS too. The academic year, the public holidays, the notices sent home to parents — in Nepal, these are set and communicated in BS first. AD is the calendar most software defaults to, but it is rarely the calendar a Nepali school actually thinks in. We built the PDP Shikshya calendar to hold both, at the same time, without asking anyone to do the conversion in their head.
The date that actually matters
Every school event in PDP Shikshya — a holiday, an exam window, a parent meeting, a sports day — carries a date in both Bikram Sambat and Gregorian. Not one converted for display purposes while the other is the 'real' one underneath. Both are genuinely stored and genuinely usable. A school admin entering the Dashain holidays can type them in as BS dates directly, the way they appear on the government's own calendar and the way they'll be announced to parents. There is no intermediate step where someone has to first figure out what that BS date is in AD before the system will accept it.
That distinction — entering dates in BS rather than translating them into BS after the fact — is small to describe and easy to get wrong in practice. A lot of systems that claim BS support really mean an AD calendar with BS numbers printed next to it, calculated once for display. Ours treats BS as an input format, not just an output label, which matters the moment a school's actual planning happens in BS terms from the start, as it does for most institutions in Nepal.
Why BS support is not a label swap
The reason this needs real engineering, rather than a translation table, comes down to how the two calendars actually relate to each other. Bikram Sambat and the Gregorian calendar do not sit at a fixed offset. Popular shorthand puts BS about 56 years and 8 months ahead of AD, but that gap is not constant across the year, and BS months do not map cleanly onto AD months — a BS month can be 29, 30, 31, or 32 days long depending on the year, following a lunisolar structure quite different from the fixed 28-31 day AD months most calendar libraries assume.
The BS new year itself does not land on a fixed AD date either — Baisakh 1 typically falls in mid-April, but the exact day shifts year to year. So a naive 'add roughly 57 years' conversion will drift, sometimes by a full day, right around month boundaries and year boundaries — precisely the boundaries a school calendar cares about most, since that is where term starts, exam periods, and public holidays tend to sit. Getting this right meant building actual BS-AD conversion logic with a proper reference table of BS month lengths, not a shortcut formula that happens to work most of the time.
What this looks like day to day
In practice, the calendar is available in three views, and every one of them carries both date systems rather than picking a side:
- List view — a running feed of upcoming events, each one showing its BS and AD date together, useful for a quick 'what's coming up this week' check.
- Month view — a traditional grid, laid out by whichever calendar is set as default, with the other calendar's date visible on each cell.
- Year view — the full academic year at a glance, useful for planning exam schedules and long-lead holidays against both systems at once.
A teacher scheduling a unit test three weeks out does not need to know today's AD date to figure out what BS date that lands on, and a parent checking a notice that only mentions the AD date does not need to reach for a conversion app either. Both readings are always present, always accurate, and always derived from the same underlying event — not two separately maintained fields that can quietly drift out of sync.
Letting a school choose its default
Not every school leans the same way in daily use. Some run almost entirely in BS — announcements, report cards, internal memos, all dated the Nepali way, with AD showing up only when a form or an external body requires it. Others, particularly schools with more international curriculum ties or administrative software historically built around AD, have staff who default to thinking in Gregorian terms out of habit. Neither is wrong, and we did not think it was our place to decide for a school which calendar its staff should see first.
So the school admin sets the default calendar for their institution, marked distinctly in the settings with a star so there is no ambiguity about which one is primary. That default governs which date leads in the month grid and which one a staff member sees first when they open an event. The other calendar is never hidden — it is simply secondary in the display order. Changing the default does not touch a single stored date; it only changes which one is shown first, because both were always there.
A gap that generic platforms tend to leave open
This kind of decision is easy to miss if you are not building specifically for Nepal. Most school software, and most general productivity software, is built with a Western, Gregorian-first audience as the implicit default, and everything else is treated as a localization pass added later — usually a translated interface, sometimes a different date-formatting string, rarely a genuinely different calendar system running underneath. That approach can work fine for language and currency. It works less well for a calendar system, because a calendar is not cosmetic — it is the structure that exam schedules, term dates, and public holidays are actually built on.
When BS is bolted on as a secondary conversion over an AD-first system, the seams tend to show exactly where they matter most: at month boundaries, at the new year, in year-view planning. A platform that treats BS as load-bearing from the beginning, rather than as an afterthought layered over an international product, is making a quieter kind of statement about who it was actually built for. That is less a feature claim than a design posture, and it is one we think shows up in the details rather than in a marketing line.
The trade-offs we did not paper over
None of this made the calendar simpler to build, and we do not pretend otherwise. Maintaining an accurate BS reference table, testing conversion accuracy at every month and year boundary, and making sure both calendars stay in lockstep across List, Month, and Year views took real, ongoing attention — this is not a one-time calculation you write once and forget. There is also a genuine design question every school has to answer for itself: which calendar leads. We did not try to resolve that with a single global choice, because the honest answer is that it depends on the school, and sometimes on who in the school you ask.
A calendar is not cosmetic. It is the structure a school's whole year is built on, and it deserves to be treated that way from the start, not patched in afterward.
— PDP Shikshya product notes
Built for the calendar Nepali schools already use
The goal here was never to make BS look supported. It was to make sure a school office, a teacher, or a parent could read the school year the way they already think about it — without a mental subtraction, without a secondary app, without wondering which of two dates on a printed notice is the one that actually counts. Bikram Sambat and Gregorian sit next to each other in the calendar because that is how the school year genuinely runs in Nepal, and a platform built for Nepali schools should start from that fact rather than arrive at it later.