### Summary MongoDB currently lacks native field types for **date-only** (e.g., `2025-05-28`) and **time-only** (e.g., `13:45:00`) values. This results in frequent developer confusion, incorrect behavior around time zones, wasted storage, and the need for error-prone workarounds in application code. Other modern databases and languages offer dedicated types for these partial temporal values — MongoDB should as well. --- ### Problems #### 1. Timezone Shifts and Incorrect Behavior MongoDB’s `Date` BSON type stores full datetime values in UTC. If a developer stores a date-only value like `2025-06-01T00:00:00.000Z`, clients in a negative timezone (e.g., UTC-6) will see `2025-05-31` — a different day altogether. Similarly, storing a time-only value (e.g., `13:30`) requires embedding it in an arbitrary full datetime like `1970-01-01T13:30:00Z`, which: * Is misleading (why that date?), * Can shift time unintentionally due to DST or timezone assumptions, and * Makes queries like "before 14:00" more complex and error-prone. #### 2. Inadequate Workarounds for Time-Only Data Since MongoDB has no `time` type, developers use strings (`"13:45"`), integers (`1345`), or embed the time in a dummy date. All of these introduce serious issues: * **Loss of type safety and query power** (can’t use `$gte`, `$lt` with strings consistently) * **Sorting bugs** (e.g., `"9:00"` comes after `"10:00"` lexically) * **Poor index support** (no efficient numeric range queries on strings) * **Manual parsing and validation burden** in every consuming app * **Data inconsistency** when different developers or services choose different formats #### 3. Increased Storage and Reduced Clarity Using full datetime objects when only a date or time is needed increases document size unnecessarily. This reduces performance in large collections and makes the intent of stored data unclear to developers or downstream systems. #### 4. Developer Frustration and Compatibility Issues MongoDB’s close ties with JavaScript (via Node.js and Mongo Shell) make this particularly painful. JavaScript’s native `Date` object is already UTC-based and lossy for partial values. This forces developers to use libraries like `dayjs`, `luxon`, or string manipulations — none of which are consistent, built-in, or portable. --- ### Comparisons with Other Systems Many modern databases and languages already support this separation of concerns: **PostgreSQL** * Date-only Support: DATE * Time-only Support: TIME **MySQL** * Date-only Support: DATE * Time-only Support: TIME **Python** * Date-only Support: datetime.date * Time-only Support: datetime.time **Java** * Date-only Support: LocalDate * Time-only Support: LocalTime **C# (.NET 6+)** * Date-only Support: DateOnly * Time-only Support: TimeOnly **JavaScript** * Date-only Support: Temporal.PlainDate (Stage 3+) * Time-only Support: Temporal.PlainTime (Stage 3+) In particular, **JavaScript’s Temporal API**, now available in Firefox 139+, introduces `Temporal.PlainDate` and `Temporal.PlainTime` types for exactly these use cases — acknowledging this long-standing need in date/time semantics. #### Lack of Native Support in Other NoSQL Databases Even among specialized or enterprise-grade NoSQL databases, there is no native support for date-only or time-only types. Databases like Cassandra, Cosmos DB, RavenDB, and time-series databases such as InfluxDB all rely on full datetime formats or ISO 8601 strings for temporal data. This absence highlights a significant and persistent limitation across the NoSQL ecosystem. MongoDB has the opportunity to lead by addressing a gap that even its most capable peers have left unresolved — improving clarity, precision, and developer experience for a wide range of common use cases that don’t require full datetime semantics. --- ### Proposed Solution Introduce two new BSON types (and corresponding schema support): * **`DateOnly`**: Stores just a calendar date (e.g., `2025-06-01`) with no timezone or time portion. * **`TimeOnly`**: Stores only the time of day (e.g., `13:45:00`), ideally with optional milliseconds support. These types should: * Be timezone-agnostic * Support `$gte`, `$lt`, sorting, and indexing * Reduce document size when storing partial date/time values * Eliminate developer confusion and DST-related bugs * Improve integration with modern languages and libraries --- ### Use Cases * **Date-Only**: * Birthdays * Check-in/check-out dates * Holidays and recurring calendar events * Scheduling rules (e.g., "every Monday starting June 1") * **Time-Only**: * Store hours, business open/close times * Reminders or recurring alarms * Event scheduling templates ("Start at 14:00 every day") * Time-based access control