React Native DateTimePicker wraps three native pickers behind one prop list that only half applies to you

Three native dialogs behind one import

The package describes itself as a date and time picker component for React Native, and the README puts it plainly: a React Native date and time picker component for iOS, Android and Windows, with a note that Windows is not actively maintained. The design follows from that. Rather than draw its own calendar, the component delegates to what the operating system already ships: the iOS wheel-style picker, the Android dialog with its calendar and clock modes, and on Windows a separate control again.

The repository tree shows the weight of that approach. Alongside `src/` there are `ios/`, `android/` and `windows/` directories, and a `RNDateTimePicker.podspec` at the root for CocoaPods. The published `files` list in `package.json` ships all of those native directories plus `src`, `jest` and `flow-typed`, which tells you the native code is part of the package rather than something patched in afterwards.

  "name": "@react-native-community/datetimepicker",
  "version": "9.2.1",
  "main": "./src/index.js",
  "types": "src/index.d.ts",

The one thing that travels everywhere is the timezone handling, because that is JavaScript's job rather than the platform's.

Installing through Expo, and the namespace change coming with a major bump

The module is bundled with Expo Go, and the README warns about the consequence: Expo Go may not carry the newest version of the module, so the newest features and bugfixes may not be available there. The install command it gives is deliberately not npm or yarn:

npx expo install @react-native-community/datetimepicker

Expo picks the newest version compatible with your SDK, which the README is quick to point out may not be the newest version of the module. If you are on a Dev Client rather than Expo Go, it says to rebuild the client after installing dependencies. If you run `expo prebuild` and build native projects with EAS Build or locally, it says you can use the latest version of the module. That three-way split in guidance is the practical shape of Expo support: least current in Expo Go, fully current after prebuild.

The bigger thing to plan around is the package name. The README states the repository was moved out of the React Native community GitHub organization in accordance with a proposal, that the module is still published on npm under the old namespace, and that it will be published under a new namespace at some point with a major version bump. A major bump with a rename means your `package.json` will need editing and your imports updated, and it also means an `expo install` that assumes the community namespace will eventually resolve to a different package name.

Reading the prop table as three partial APIs

The most useful thing in the README is also the least attractive: the table of contents lists every prop with a platform annotation attached, and those annotations are the actual API documentation in miniature. A handful to sort through:

`value` is the only prop marked required. `mode`, `display`, `maximumDate`, `minimumDate` and `minuteInterval` are unmarked, meaning they are shared. Then the annotations split hard. `textColor`, `accentColor`, `themeVariant`, `locale`, `style`, `disabled` and the view props are iOS only. `design`, `initialInputMode`, `title`, `fullscreen`, `startOnYearSelection`, `positiveButton`, `negativeButton`, `neutralButton`, `onNeutralButtonPress` and `onError` are Android only. `timeZoneOffsetInSeconds`, `dayOfWeekFormat` and `dateFormat` are Windows only, and `is24Hour` covers Windows and Android but not iOS, which has its own locale conventions.

Two entries in that list are worth pausing on. `onChange` is annotated as optional and deprecated, with `onValueChange` sitting alongside it, so code written against older releases is calling a prop the project would rather you moved off. And `fullscreen` being Android only means a design that assumes a full-screen date picker on iOS has no equivalent prop to reach for.

That per-platform spread is the practical cost of the wrapper approach, and it is why the README's prop documentation, rather than a quick start snippet, is the thing to read before writing any code.

New architecture support and how the native code gets linked

The Requirements section is one sentence and it is load-bearing. The module supports the new React Native architecture, which the README names specifically as Fabric rendering of iOS components and turbomodules on Android. That is the difference between a component that needs the interop layer to work and one that does not, and it is the single most consequential line for anyone on a recent React Native version.

Linking happens in two ways, and the tree shows both. For bare React Native there is `react-native.config.js` alongside the podspec, which is the standard autolinking entry point, plus a Manual installation section in the README for anyone who is not relying on autolinking. For Expo there is an `app.plugin.js` at the root and a `plugin/` directory, which together are an Expo config plugin: they exist so the native project can be configured during prebuild without hand-editing Podfiles or Gradle files.

The test and type story in the repository is also unusually complete for a component. `package.json` wires up Jest, ESLint, Flow and Detox end to end:

    "test": "jest",
    "lint": "NODE_ENV=lint eslint {example,src,test}/**/*.js src/index.d.ts",
    "flow": "flow check",

The source is JavaScript with Flow types checked through a `.flowconfig` and `flow-typed/`, and TypeScript declarations shipped separately at `src/index.d.ts`. Both type systems are supported, which costs the maintainers something and tells you the audience is larger than one typing preference.

Timezone props and a test suite that pins the clock

Timezone is where a date picker most often produces a bug that only shows up for users in one region, and this project treats it as a first-class concern. There are three separate props: `timeZoneName`, then `timeZoneOffsetInMinutes` marked for iOS or Android, and `timeZoneOffsetInSeconds` marked Windows only. The asymmetry between minutes and seconds is not a mistake in the docs so much as a reflection of two different platform conventions, and the Windows entry was still being fixed recently: the v9.2.1 release notes list a change to respect the `timeZoneOffsetInSeconds` prop on Windows.

The end-to-end setup backs that up. The Detox scripts in `package.json` set a fixed timezone for the simulator before running the suite, on both debug and release configurations:

    "detox:ios:test:debug": "SIMCTL_CHILD_TZ=Europe/Prague detox test -c ios.sim.debug -l verbose",

Pinning a timezone rather than inheriting the developer's is the difference between a date test that means something and one that passes in Prague and fails in San Jose. There is a `.detoxrc.js` at the root for the configurations, an `example/e2e/` directory, and a Jest section in the README's table of contents, with `jest/` and `jest.config.js` shipped in the package so the mock helper is available to consumers who test components that render a picker.

The other thing to know about dates here is that the picker hands you a `Date` and a mode. Whether you store local time, UTC or a zone identifier is your decision, and nothing in the component's prop list settles it for you.

Cadence, licensing and the Windows caveat

Three recent releases show what kind of project this is. Version 9.1.0 on 2026-03-17 introduced more granular event listeners. Version 9.2.0 on 2026-08-31 added an Android inner time picker text colour, corrected a Flow prop type on iOS that had been named `enabled` instead of `disabled`, and made config plugins resolve through Expo. Version 9.2.1 on 2026-09-07 reopened the picker when the Android `design` prop changes, skipped the explicit Kotlin plugin when AGP provides a built-in one, allowed the `design` argument in the Android dismiss call, and fixed the Windows timezone offset prop. GitHub reports the last push on 2026-09-07, the same day as that release.

Two of those fixes are Android build-system chores rather than picker features, and that is a fair signal of where the work goes: keeping a native module building across changing React Native and Android toolchains takes more effort than adding a prop. The Expo config plugin resolution in 9.2.0 and the built-in Kotlin plugin handling in 9.2.1 both point at installation friction rather than date arithmetic.

The Windows position is the one to weigh before committing. The README parenthesises that Windows is not actively maintained, and the last Windows change in the release notes is a bugfix rather than a feature. There is a `windows/` directory and example app, so the platform still builds, but if Windows is a shipping target for you, treat it as best effort. The README also opens by asking for collaborators and financial backers, pointing at an issue for context, which is a reasonable signal about how much review capacity the project has. The licence is MIT, and the `example/` directory carries run targets for Android, iOS, macOS, visionOS and Windows, so the sample app is the fastest way to see what the picker actually looks like on your platform of interest.

Editorial conclusion

This component earns its place when the platform's own date wheel is acceptable to your users, because handing the interaction to UIKit or the Android dialog is what buys you the accessibility and localisation behaviour you would otherwise spend weeks rebuilding. Read the prop table as three partial APIs rather than one, since `textColor` and `accentColor` are iOS-only while `positiveButton`, `fullscreen` and `design` are Android-only and `dayOfWeekFormat` is Windows-only. Before adopting it, check the package name you intend to depend on: the repository has left the React Native community organization and states that a new namespace arrives with a major version bump, so pin the version and re-check on upgrade. If your requirement is a single identical UI on every platform, the alternative is a pure JavaScript date library in a modal you build yourself, which trades platform fidelity for cross-platform consistency.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. react-native-datetimepicker/datetimepicker on GitHub
4. README
5. Releases