A Bikram Sambat website should store dates in Gregorian and convert to BS only for display. Bikram Sambat month lengths are not calculable by a formula, so every conversion library relies on lookup tables with a limited supported range. Store what is stable, display what people read.
Most calendar bugs on Nepali websites come from one mistaken assumption: that Bikram Sambat works like the Gregorian calendar with different numbers. It does not, and the difference is structural rather than cosmetic.
Bikram Sambat cannot be calculated with a formula
In the Gregorian calendar, January always has 31 days and February follows a leap year rule you can write in three lines of code. Any date, past or future, is computable.
Bikram Sambat does not work that way. Month lengths vary year to year, because month boundaries are determined by the sun’s transition between zodiac signs, the Sankranti, calculated in Nepal local time. A given month may have 29, 30, 31 or 32 days depending on the year.
So there is no arithmetic that converts a BS date reliably. Every library that does it correctly ships a lookup table of month lengths, generated either from published calendar data or from astronomical calculation. One Rust implementation describes exactly this, combining lookup tables for historical accuracy with an astronomical engine for precision.
Two consequences follow, and both matter for anything you build:
- You cannot write your own converter with a quick formula. Attempting it produces something that works for the current year and fails silently later.
- Conversions outside a library’s data range are unreliable or unavailable, which is the next section.
Every conversion library has a supported range
This is the detail that catches developers, because a date library usually feels boundless.
Ranges differ substantially between implementations. One widely used JavaScript converter supports 1975 BS to 2099 BS, equivalent to 1918 AD to 2043 AD, in a bundle of roughly five kilobytes. A Python library covers a wider span of approximately 1901 BS to 2199 BS. Another JavaScript library covers 1970 BS to 2111 BS. A Rust implementation uses lookup tables for 1975 to 2100 BS and switches to astronomical calculation beyond that.
Check the range against what your application actually needs. A school storing dates of birth for staff may reach back further than a converter built for recent records. A system recording long leases or historical land records can reach forward past 2099 BS more easily than you would expect.
One honesty point that library authors themselves raise. The Python implementation notes plainly that its calendar data is aggregated from various public sources and existing implementations. Different libraries can therefore disagree on the length of a particular month in a particular year, especially at the edges of their ranges. If two systems in your organisation use different libraries, they can produce different dates for the same input.
So pick one library per project, and use the same one everywhere, including any background jobs and reports.
Which date should your database store?
Gregorian, in a standard date column, always. Convert to Bikram Sambat only when you display it.
The reasoning is practical rather than ideological. Gregorian dates sort correctly, compare correctly, work with every date function your database provides, and never need a lookup table to answer a question like which notices were published in the last thirty days. Store BS as text and all of that breaks.
If you also store the BS date for convenience, treat it as a derived, secondary field that can be regenerated at any time. Never let it become the authoritative value, because the moment your conversion library updates, your stored strings and your live conversions can disagree with no way to tell which is right.
| Where the date appears | Show which calendar | Why |
| Notices for a Nepali audience | BS leading, AD alongside | Readers plan in BS; software and search need AD |
| Government and compliance deadlines | BS leading | The deadline is defined in BS |
| Blog and news publication dates | AD in markup, BS on screen | Search engines read structured data in AD |
| Anything read by people abroad | AD leading | A BS date alone is unreadable to them |
| Database storage | AD only | Sortable, comparable, and never needs a lookup table |
The forty-five minute problem
Nepal Standard Time is UTC plus five hours and forty-five minutes. It is one of very few timezones offset by a partial hour, and it breaks assumptions in software written elsewhere.
Where it bites: your server almost certainly runs in UTC, which is correct practice. A notice published at 5:30am Nepal time is stored as the previous day in UTC. If your BS conversion runs against the stored UTC value without converting to Nepal time first, the notice shows the wrong Bikram Sambat date. It will be wrong for a window every single day, which is why this bug survives casual testing.
The same offset affects the calendar itself. Because month boundaries depend on solar transitions calculated in Nepal local time, the timezone is not merely a display concern. It is part of how the calendar is defined.
Three rules that avoid the whole class of problem. Store timestamps in UTC. Convert to Nepal time before deriving any BS date. And test around midnight and early morning, not at 2pm when everything looks fine.
Choosing a date picker
If Nepali users enter dates, they should enter them in Bikram Sambat. Asking someone to convert their own date of birth before typing it is a reliable way to collect wrong data.
Ready-made components exist, including React components for BS calendars and pickers, and Android widgets for BS date input. Using one is almost always better than building your own, for the same reason as the conversion itself.
What to check before adopting one:
- The supported year range, particularly for dates of birth reaching decades back.
- Whether it displays Devanagari numerals and Nepali month names, or only Latin ones.
- Whether it works on a phone, since that is how most users will meet it. Small tap targets in a calendar grid are a common failure.
- Whether it returns a Gregorian value to your form, so your backend stores the right thing without a second conversion.
- Whether it is still maintained, since an abandoned picker eventually breaks against a framework upgrade.
For a simple form, consider offering both. A BS picker for Nepali users and a standard date field for anyone else, with a clear label saying which calendar each expects. Ambiguity here produces silently wrong data rather than an error message.
Nepali numerals and month names
Displaying a converted date as 2083-05-22 is technically correct and reads as foreign to a Nepali audience.
Conversion libraries commonly offer Devanagari output, producing dates in Nepali numerals and month names rather than Latin digits. For a Nepali-facing notice board or calendar, that is the right presentation.
Two cautions. Keep the machine-readable date in Latin digits inside your structured data and markup, since search engines and other software read those and Devanagari numerals in a date field will not parse. And be careful with month name spelling, since transliterations vary and inconsistency across a site looks careless to a Nepali reader even when the date is correct.
The wider question of getting Nepali text stored and rendered correctly, including the encoding settings that affect all of this, is covered in our guide to Nepali Unicode on websites.
The fiscal year catches everyone
Nepal’s fiscal year runs from Shrawan to the end of Ashadh, not from January or from April. Any reporting feature, invoice numbering scheme or annual summary built on a Gregorian year boundary will be wrong for every Nepali organisation using it.
This affects more than accounting software. Annual reports, membership renewals, academic sessions, government submission deadlines and subscription cycles are all commonly anchored to the Nepali fiscal year or to BS month boundaries.
Ashadh deserves a specific mention, because it can run to 32 days. Code that assumes a maximum of 31 days in a month will reject a valid date at exactly the end of the fiscal year, which is the worst possible moment for a finance team to discover it.
If you are scoping a site that needs this kind of local handling, our website design and development service covers it, and the broader planning question is in our guide to what a Nepali business website needs.
What actually breaks in practice?
A short checklist worth running against any Nepali site before launch.
- Enter a date in the first week of Baishakh and confirm the year rolls over correctly.
- Enter a date on the 32nd of Ashadh in a year that has one, and confirm it is accepted.
- Publish something at 5am Nepal time and check the displayed BS date is right.
- Enter a date of birth from forty years ago and confirm the picker allows it.
- Sort a list of records by date and confirm the order is correct, which tells you whether you are sorting on the stored Gregorian value or on a BS string.
- View the same record in two different parts of the system and confirm the BS dates agree.
Every one of those has produced a real bug on a real Nepali site. The last is the most insidious, because it usually means two components are using different conversion libraries and nobody noticed until a user pointed it out.
Frequently asked Questions
No. BS month lengths vary between years because month boundaries follow the sun’s transition between zodiac signs, calculated in Nepal local time. Months can have 29 to 32 days. Every accurate converter relies on lookup tables or astronomical calculation rather than arithmetic.
Store Gregorian in a proper date column and convert to Bikram Sambat for display. Gregorian sorts and compares correctly and works with your database’s date functions. If you store BS as well, treat it as a regenerable secondary field, never the authoritative one.
Almost always the timezone. Nepal is UTC plus 5:45, and servers usually run in UTC, so anything published in the early morning Nepal time falls on the previous UTC day. Convert to Nepal time before deriving the BS date, and test around midnight rather than midday.
It varies by library. Ranges in common use include 1975 to 2099 BS, 1970 to 2111 BS, and roughly 1901 to 2199 BS. Check the range against your actual needs, since dates of birth reach further back and long leases reach further forward than people expect.
Yes, particularly near the edges of their supported ranges, because calendar data is aggregated from various public sources and implementations differ. Use one library consistently across your entire project, including background jobs and reports.
It runs from Shrawan to the end of Ashadh, so any annual reporting built on a Gregorian year boundary will be wrong. Note also that Ashadh can have 32 days, and validation code assuming a 31-day maximum will reject a valid date at the fiscal year end.
