How does BSON store a Date, and how does it differ from the BSON Timestamp type?

## BSON Date The `date` BSON type is a **signed 64-bit integer counting milliseconds since the Unix epoch** (1970-01-01T00:00:00Z). In mongosh you create one with `new Date()` or `ISODate("…")`, and it displays in ISO-8601 form — but the stored value is just that integer. Two consequences follow directly from the representation: - **Signed, so pre-1970 dates work.** A birth date in 1948 is a negative millisecond count and stores and compares perfectly well. - **Millisecond resolution.** Sub-millisecond precision does not survive; if you need microseconds, keep them in a separate numeric field. ## No timezone is stored A `Date` records an **instant**, not a wall-clock reading. `ISODate("2026-03-01T09:00:00+01:00")` and `ISODate("2026-03-01T08:00:00Z")` are the same instant and produce identical stored bytes; the offset in the literal is used to interpret the input and is then discarded. Drivers hand the value back as their platform's UTC-based date type, and the display timezone is a property of the client, not of the data. This is the right default — instants compare and sort correctly across regions, and range queries are unambiguous. But it means a domain that genuinely cares about local wall-clock time must store the extra information itself: keep an IANA zone name such as `"Europe/Berlin"` in a sibling field. An offset alone is not enough for future dates, because the offset a zone uses changes with daylight-saving rules. "09:00 local, every Monday" is a wall-clock fact; the instant it corresponds to next November is derived from the zone, not stored with the date. ## BSON Timestamp is not a date `Timestamp` is a separate BSON type: a 64-bit value made of a seconds component and an ordinal counter that distinguishes multiple operations within the same second. MongoDB uses it **internally**, principally in the oplog, where operations must be totally ordered. It has a special server-side behaviour that catches people out: if you insert a document containing an **empty** `Timestamp()` value in a top-level field, the server replaces it with the current timestamp. A field you expected to hold a placeholder comes back holding a value you did not write. Its resolution is coarser than `Date` (seconds plus an ordinal), it carries no timezone semantics, and drivers surface it as a special type rather than a native date. For application data — created-at, updated-at, event time, expiry — always use `Date`. ## Ordering In BSON's cross-type comparison order, `Date` and `Timestamp` sit in adjacent but distinct positions, with `Date` ranking below `Timestamp`. So a field that accidentally holds a mix of the two sorts into two blocks, and a range query written with `ISODate` bounds will not match the `Timestamp`-typed rows at all — the same silent-miss failure that mixed numeric and string types produce. ## Practical guidance Store instants as `Date`. Store the zone separately when local time is part of the domain. Query with `ISODate` bounds so both sides of the comparison are the same type. Reserve `Timestamp` for reading MongoDB's own internal metadata, and never write it into your own schema by hand. And when a date arrives as a string from an external feed, convert it at ingestion — a date stored as a string sorts lexicographically, which happens to work for full ISO-8601 UTC strings and fails for every other format.