The date format converter accepts any date string or timestamp as input and instantly shows the equivalent value in 10 common formats side by side: Unix timestamp, ISO 8601, RFC 3339, RFC 7231, UTC, ISO 9075, MongoDB ObjectId, Excel serial number, JavaScript timestamp, and a custom format you define. It is the quickest way to reconcile date format mismatches across databases, APIs, or systems.
Which Format Belongs Where
| Format | Example | Typical use |
|---|---|---|
| ISO 8601 | 2024-12-19T10:30:45.123Z | JSON APIs, database storage, internationalized apps |
| ISO 9075 | 2024-12-19 10:30:45.123 | MySQL, PostgreSQL queries |
| RFC 3339 | 2024-12-19T10:30:45+08:00 | Internet protocols, OpenAPI specs |
| RFC 7231 | Thu, 19 Dec 2024 10:30:45 GMT | HTTP headers: Last-Modified, Expires |
| Unix timestamp (seconds) | 1703038245 | System logs, cache TTL, token expiry |
| JavaScript timestamp (ms) | 1703038245123 | Date.now(), frontend time comparisons |
| MongoDB ObjectId | 675436e50000000000000000 | Reverse-looking up document creation time |
| Excel serial number | 45644.4378 | Excel import/export, financial reports |
Timezone Edge Cases
The tool parses input using dayjs, so timezone behavior depends on the format:
- ISO 8601 / RFC 3339: If the input carries a timezone offset like
+08:00orZ, dayjs preserves it and the RFC 3339 output includes the correct offset. - Locale format: Uses the browser's current system timezone. The same input will produce different "local" strings on machines set to different timezones.
- ISO 9075 / RFC 7231: Formatted in local timezone — note this when sharing results across timezone boundaries.
- Unix timestamp / UTC: Always UTC, no timezone ambiguity. These two are the safest formats for passing time between systems.
Daylight saving time boundaries: If an input time falls exactly on a DST transition (such as the 2:00 AM changeover in European/American autumn), some output formats may show a repeated or skipped hour. This reflects standard timezone behavior, not a bug.
Extracting Creation Time from a MongoDB ObjectId
The first 8 hex characters of an ObjectId encode a Unix timestamp in seconds. The tool extracts those 8 characters and appends 16 zeros to produce a valid-looking 24-character ObjectId. The reverse is also supported: paste a real ObjectId and the tool derives the document's creation time from the first 8 characters.
Custom Format Syntax
The custom format field accepts dayjs format tokens. Common tokens:
YYYY— four-digit year;YY— two-digitMM— month (01–12);M— without leading zeroDD— day (01–31);D— without leading zeroHH— 24-hour;hh— 12-hour;mm— minutes;ss— secondsX— Unix seconds;x— Unix milliseconds
Mixing up MM (month) with mm (minutes) or HH (24-hour) with hh (12-hour) is the most common reason a custom pattern produces unexpected output.