Date Formats in REST APIs and JSON
Best practices for date formatting in REST APIs and JSON payloads. Covers ISO 8601, Unix timestamps, RFC 3339, and handling timezone information in API design.
Detailed Explanation
Date Formats in APIs and JSON
Choosing the right date format for your API is a critical design decision that affects interoperability, timezone handling, and developer experience. This guide covers the most common approaches and their trade-offs.
The Three Main Approaches
1. ISO 8601 / RFC 3339 String
{
"created_at": "2026-02-28T14:30:00Z",
"updated_at": "2026-02-28T14:30:00+09:00"
}
2. Unix Timestamp (Integer)
{
"created_at": 1772236800,
"updated_at": 1772236800000
}
3. Custom String Format
{
"created_at": "02/28/2026 2:30 PM"
}
Recommendation: ISO 8601 / RFC 3339
The overwhelming industry consensus is to use ISO 8601 (specifically RFC 3339, which is a profile of ISO 8601):
"2026-02-28T14:30:00Z"
Reasons:
- Human-readable — developers can inspect payloads visually
- Timezone-aware — the offset is part of the string
- Widely supported — every language has built-in parsing
- Sortable — lexicographic sorting = chronological sorting
- Industry standard — used by GitHub, Stripe, Twilio, AWS
When to Use Unix Timestamps
Unix timestamps make sense for:
- JWT claims —
exp,iat,nbfare defined as Unix seconds - High-frequency data — financial tickers, IoT sensor data
- Simple comparison — numeric comparison is faster than string parsing
- Existing systems — databases storing timestamps as integers
API Design Best Practices
- Always include timezone info — never send "2026-02-28T14:30:00" without offset or Z
- Use UTC for storage — convert to local time only on the client
- Document your format — specify ISO 8601/RFC 3339 in your API docs
- Be consistent — use the same format for all date fields
- Use seconds precision by default — add milliseconds only if needed
- Accept multiple formats on input — be liberal in what you accept
- Consider pagination — cursor-based pagination with timestamps needs precision
Framework Defaults
| Framework | Default Format |
|---|---|
| Rails | ISO 8601 (2026-02-28T14:30:00.000Z) |
| Django REST | ISO 8601 (2026-02-28T14:30:00Z) |
| Spring Boot | ISO 8601 (2026-02-28T14:30:00+09:00) |
| Express/Node | Date.toISOString() (2026-02-28T14:30:00.000Z) |
| Go (encoding/json) | RFC 3339 (2026-02-28T14:30:00Z) |
| ASP.NET | ISO 8601 (2026-02-28T14:30:00+09:00) |
Use Case
Date format decisions affect every API consumer. This is relevant for REST API design, GraphQL schema definition, webhook payload specifications, SDK and client library implementations, API documentation, and database schema design for timestamp columns.