React Native DateTimePicker

@react-native-community/datetimepicker renders each platform’s native date and time picker inside a React Native app, wrapping UIDatePicker on iOS, the classic and Material dialogs on Android, and the Windows date/time controls behind one shared component API. Rather than reimplementing picker UI in JavaScript, it delegates to the OS-native widgets so apps inherit correct system look, accessibility, and localization for free.

On Android, the library also exposes an imperative DateTimePickerAndroid.open()/dismiss() API alongside the component API, mirroring how native Android apps typically summon date pickers as one-off dialogs rather than persistent components. The New Architecture (Fabric + TurboModules) is supported via codegen specs alongside the legacy Paper architecture, and the module ships as part of the Expo SDK.

What You Get

• Native picker UI - Renders the OS’s own date/time picker widgets instead of a custom JS-drawn UI, so apps automatically match platform look, feel, and accessibility.
• Component and imperative APIs - Use it as a regular <DateTimePicker> component, or call DateTimePickerAndroid.open()/dismiss() imperatively to match native Android dialog conventions.
• Material Design pickers on Android - Opt into the newer Material date/time picker dialogs via the design prop, alongside the classic system pickers.
• New Architecture support - Ships Fabric component specs and TurboModule codegen definitions for Android and iOS, alongside the legacy (Paper) architecture.
• TypeScript and Flow typings - Full index.d.ts typings plus flow-typed definitions for typed prop and event handling.

Common Use Cases

• Booking and scheduling forms - Apps that let users pick an appointment, reservation, or event date/time use it for a native, familiar picker UI.
• Profile and settings fields - Collecting a birthdate, reminder time, or recurring schedule value in account settings.
• Android imperative flows - Apps following native Android UX conventions summon the picker as a one-off dialog via DateTimePickerAndroid.open() rather than keeping it mounted.
• Expo-managed apps - Projects on Expo Go or EAS Build pull it in directly since it’s part of the Expo SDK, without needing custom native modules.

Under The Hood

Architecture src/index.js re-exports eventCreators, DateTimePickerAndroid, and a platform-resolved default export backed by Metro’s file-suffix resolution (datetimepicker.ios.js, datetimepicker.android.js, datetimepicker.windows.js, with a plain datetimepicker.js fallback that warns on unsupported platforms). On Android, picker.android.js dispatches by mode (‘date’/‘time’) to separate DatePickerAndroid/TimePickerAndroid modules, which further branch into classic-dialog and Material-dialog variants (materialdatepicker.android.js, materialtimepicker.android.js); iOS instead wraps the native Fabric component spec directly (specs/DateTimePickerNativeComponent.js) via picker.ios.js. Change events flow through eventCreators.js, which builds typed DateTimePickerEvent tuples consumed uniformly across platforms. This is a classic React Native platform-suffix architecture — one shared JS surface with no common base implementation — so each platform module owns its own dialog/native-view wiring, meaning a change to the cross-platform contract touches four parallel entry files plus the TurboModule/Fabric codegen specs under src/specs.

Tech Stack The cross-platform layer is Flow-typed JavaScript (@flow strict-local), paired with TypeScript typings (index.d.ts) for consumers. Native implementations are Java/Kotlin on Android (RNDateTimePickerPackage.java, RNMaterialDatePicker.kt, TurboModule specs), Objective-C/Objective-C++ and C++ for iOS and its Fabric component view (RNDateTimePickerComponentView.mm), and native controls for Windows via react-native-windows. Build and release tooling includes Metro/Babel, expo-module-scripts for the config plugin, Detox for end-to-end testing, and a semantic-release pipeline wired into GitHub Actions for automated npm publishing.

Code Quality Unit tests live under test/ (index.test.js, utils.test.js, userlandTestExamples.test.js) using Jest and @testing-library/react-native, supplemented by Detox end-to-end suites for iOS and Android in the example app. Linting runs via @react-native/eslint-config plus a Flow plugin, formatting via Prettier, and CI (.github/workflows/test.yml) runs the suite on every change. Static typing is enforced on both sides — Flow for the JS source, generated TypeScript types for consumers. Error handling favors explicit console warnings for unsupported-platform fallbacks over throwing, which keeps failures visible without crashing the host app.

What Makes It Unique Rather than drawing a custom calendar/spinner UI in JavaScript like many userland alternatives, the library deliberately delegates to each OS’s native picker widgets, trading visual customization for exact platform parity. Its dual component-plus-imperative API is a direct response to Android’s native convention of summoning pickers as one-off dialogs rather than mounted components — a split most single-API RN pickers don’t offer. It also carries first-class support for both the legacy Paper architecture and the New Architecture (Fabric + TurboModules) side by side, and change events include an explicit utcOffset alongside the timestamp so consumers can reconcile timezones without a separate date library.