Mahan Fakhimi
The current
DatePicker
component is fundamentally built around the Gregorian calendar system. While it's possible to customize the formatting for display using the
format
and
parse
props, the internal logic, state management, and navigation (e.g.,
goToNext
,
getYearsGrid
) remain Gregorian.
This creates significant challenges when trying to implement a date picker for non-Gregorian calendars, such as the
Jalali (Persian) calendar
. The "masking" approach (formatting to Jalali for display) is brittle and breaks down during user interactions. For example:
  1. Incorrect Navigation:
    Clicking "next month" moves from a Jalali month to the next
    Gregorian
    month, causing confusing and incorrect behavior.
  2. State Mismatches:
    Selecting a month or year from the grid sets an incorrect internal date because the logic assumes Gregorian indices.
  3. Complex Workarounds:
    The only robust solution is to completely override the component's internal logic by managing all date state externally with a separate library. This largely defeats the purpose of using Ark UI's powerful built-in state management and requires re-implementing most of the calendar grid generation logic from scratch.
The ideal solution would be to allow developers to provide a different calendar system for the
DatePicker
to use for all its internal calculations.
The **
@internationalized/date
** library (from the Adobe team behind React Aria) is the industry standard for this. It provides robust, out-of-the-box support for many calendar systems, including a
PersianCalendar
.
A potential API could look like this:
import { DatePicker } from '@ark-ui/solid'
import { PersianCalendar } from '@internationalized/date'
const MyJalaliDatePicker = () => {
const jalaliCalendar = new PersianCalendar()
return (
<DatePicker.Root calendarSystem={jalaliCalendar}>
</DatePicker.Root>
)
}
By accepting a
calendarSystem
prop,
DatePicker
could use the provided calendar instance for all date math (adding/subtracting months, getting days in a month, etc.), making it truly locale-aware.
  1. Wrapping the Component:
    We've tried building a custom wrapper that manages all state using
    @internationalized/date
    and only uses Ark UI for rendering the final UI. This works, but it's very complex and we lose all the benefits of the built-in context and state management that make Ark UI so great.
  2. **Overriding
    format
    and
    parse
    :** As described above, this approach is not sufficient. It only changes the display value, not the underlying logic, leading to a broken user experience.
Additional context
Adding native support for different calendar systems would elevate Ark UI to a top-tier, global-ready UI library. It would be an invaluable feature for developers building applications for regions in the Middle East, Asia, and beyond who rely on calendars like Jalali, Hijri, Buddhist, etc.
Thank you for your consideration!