Handling Bikram Sambat Dates Without Breaking Everything

Store Nepali dates in AD and convert for display. That single decision prevents most of the problems below, and teams that get it wrong usually do not find out until they run their first annual report.

Bikram Sambat is about 56 years and 8 months ahead of the Gregorian calendar, and the offset is not constant, because the new year falls in mid-April rather than January. That much is widely known. The parts that break software are less obvious.

Why arithmetic on BS dates is unsafe

A Gregorian month has a length you can compute from a rule. A Bikram Sambat month does not. Month lengths run from 29 to 32 days and vary by year, because the calendar is lunisolar and the boundaries come from astronomical calculation rather than arithmetic.

The practical effect: you cannot add one month to a BS date by incrementing the month number. You cannot compute the number of days between two BS dates by subtracting. Anything that looks like date maths has to go through a conversion table.

This is the argument for storing AD. Once a date is a real timestamp, every operation your database and language already provide works correctly. Conversion happens at the edge, in the view layer, where a wrong answer is visible rather than silently stored.

The lookup table has an end date

Every BS conversion library carries a table of month lengths for a range of years. Ask which range before you pick one. A library covering 2000 to 2090 BS is fine for invoices and unusable for a system that stores dates of birth for people born before that, or for a savings product with a 50-year maturity.

Test the boundaries deliberately. Convert the first and last supported dates and see what happens one day beyond each. A library that throws is easy to handle. A library that returns a plausible but wrong date is the one that costs you.

What breaks in reporting

A Nepali business runs its financial year from Shrawan to Ashadh, not January to December. If your reports group by Gregorian month, every summary you produce is misaligned with the accounts your client actually files.

This is where storing AD pays for itself again. Grouping a set of timestamps into BS months is a mapping step you can fix and re-run. Grouping stored BS strings means your historical data has already baked in whatever your conversion did at write time, including any bugs.

One more reporting trap: sorting. BS dates stored as strings in the common display format sort incorrectly whenever the day or month is written without a leading zero. If you must store a BS string, store it zero-padded, and store the AD timestamp beside it.

Input is harder than output

Displaying a converted date is straightforward. Accepting one is not. A Nepali date picker has to know the length of the selected month in the selected year before it can render, which means the picker needs the same table your backend uses.

Keep one source of truth for that table across the stack. We have seen a frontend picker and a backend validator disagree by a day at a month boundary, which produced a form that rejected a date it had just offered.

Also accept that people type dates. Give the field a clear format hint, validate against the table, and say what is wrong when validation fails. "Invalid date" tells a user nothing when the real problem is that Jestha had 31 days that year and they entered 32.

A short checklist

Before you ship anything that handles Nepali dates: confirm storage is AD in UTC, confirm the conversion table's supported range covers your data, confirm reports group by the Nepali financial year where the client expects it, and confirm the frontend and backend share one table. Four checks, and they remove most of the class.