Jalali (Persian) Dates in Online Forms: Three Mistakes That Corrupt Your Data

Every Persian-language form eventually gets to a date: date of birth, employment start date, event date. There are three mistakes almost everyone makes at least once.

Mistake one: storing the date as Jalali text

It's tempting to store "1404/06/21" exactly as it is. The problem shows up when you want to sort or filter by a date range. Sorting text compares characters, not dates: as soon as one value is written a little differently, "1404/10/01" can land before "1404/09/30", and the result is chaos.

The right way: always store the date in Gregorian/ISO format and convert to Jalali only at display time. The user sees Jalali, the database understands Gregorian, and sorting and range filtering work correctly.

Mistake two: time zones

If you convert the date to Gregorian in the user's browser and the browser is on UTC, "1404/06/21" may become "2025-09-11T20:30Z", which is still the same day in Iran but the previous day in UTC. Then your "today" report ends up a day behind.

The rule: a date without a time (date of birth, contract date) should be stored without a time zone, as a calendar day, not as an instant. Instants (the time a response was submitted) are stored with a time zone.

Mistake three: leap years

The Jalali calendar has a different leap-year pattern from the Gregorian one. The 30th of Esfand (the last month of the year) exists only in leap years. If you write date validation yourself with "day between 1 and 31," you will accept 31 Esfand (which never exists) and you may reject 30 Esfand in a leap year.

Don't write this yourself. Use a well-tested library.

A small detail that improves the experience

For date of birth, a calendar picker is a poor choice: the user has to click back 30 years. For birth dates, three dropdowns (day/month/year) or direct text entry work better. A calendar is right for nearby dates: appointment booking, meeting dates.