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:

 
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 or timezone-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