JSON does not have a native date type, so developers usually store dates as ISO 8601 strings, Unix timestamps, or custom formatted values. This creates common issues around time zones, parsing, sorting, and cross-language compatibility. In this guide, you will learn the safest JSON date formats to use, when to prefer timestamps over strings, and how to avoid the most common date-handling mistakes in APIs and databases.
ISO 8601 (YYYY-MM-DDTHH:mm:ss.sssZ) is the universally accepted format for date strings in JSON APIs. It's unambiguous, sortable as a string, and supported by every major language's date parser. The T separates date and time. The Z suffix indicates UTC. Timezone offsets use +HH:MM/-HH:MM (e.g., 2026-04-29T10:30:00+08:00 for Beijing time).
ISO 8601 Format Breakdown
| Format | Example | Use Case |
|---|---|---|
| Date only | 2026-04-29 | Birthdays, publication dates |
| Date + time | 2026-04-29T14:30:00 | Events, schedules |
| With timezone Z | 2026-04-29T14:30:00Z | API timestamps (UTC) |
| With offset | 2026-04-29T22:30:00+08:00 | Local time with offset |
| With milliseconds | 2026-04-29T14:30:00.123Z | High-precision logging |
| Unix timestamp | 1745917800 | Compact, language-agnostic |
JavaScript: Parsing and Formatting Dates
// Parsing ISO 8601 (built-in support)
const dateStr = '2026-04-29T14:30:00Z';
const date = new Date(dateStr);
console.log(date.toISOString()); // 2026-04-29T14:30:00.000Z
// WARNING: new Date() with non-ISO strings is unreliable
new Date('04/29/2026'); // May differ across browsers!
new Date('2026-04-29'); // Parsed as UTC midnight usually safe
// Formatting dates for JSON output
function toJsonDate(date) {
return date.toISOString(); // Always returns UTC ISO 8601
}
// For user-facing dates, use Intl
const userDate = new Intl.DateTimeFormat('en-US', {
dateStyle: 'medium',
timeStyle: 'short',
timeZone: 'America/New_York'
}).format(date); // "Apr 29, 2026, 10:30 AM" ' + '
// DANGER: Date-only strings are parsed as UTC midnight
const date = new Date('2026-04-29');
console.log(date.toISOString()); // 2026-04-29T00:00:00.000Z “
// But local time display depends on YOUR timezone
console.log(date.toLocaleDateString());
// In UTC-5: "4/28/2026" …WRONG! It shifted to previous day!
// SAFE: Always include time and timezone for precision
const safe = new Date('2026-04-29T12:00:00Z');
console.log(safe.toLocaleDateString('en-US'));
// "4/29/2026" “Consistent regardless of viewer's timezone
Python: Date Handling with datetime
from datetime import datetime, timezone
import json
# Parse ISO 8601
date = datetime.fromisoformat('2026-04-29T14:30:00+00:00')
print(date) # 2026-04-29 14:30:00+00:00
# Serialize to ISO 8601
print(date.isoformat()) # 2026-04-29T14:30:00+00:00
# Custom JSON encoder for datetime objects
class DateTimeEncoder(json.JSONEncoder):
def default(self, obj):
if isinstance(obj, datetime):
return obj.isoformat()
return super().default(obj)
data = {
"event": "deploy",
"timestamp": datetime.now(timezone.utc),
"duration_seconds": 45.2
}
json_str = json.dumps(data, cls=DateTimeEncoder)
# {"event": "deploy", "timestamp": "2026-04-29T08:57:46.123456+00:00", ...}
# Parse JSON dates back to datetime
def parse_dates(obj):
if isinstance(obj, str):
try:
return datetime.fromisoformat(obj)
except ValueError:
return obj
if isinstance(obj, dict):
return {k: parse_dates(v) for k, v in obj.items()}
if isinstance(obj, list):
return [parse_dates(v) for v in obj]
return obj
parsed = json.loads(json_str, object_hook=parse_dates)
API Design: Date Best Practices
For API responses, always return dates in ISO 8601 with timezone information (Z for UTC, or explicit offset). Accept flexible input formats but normalize to ISO 8601 internally. Use UTC for all server-side storage and processing convert to local time only at the display layer. For date-only fields (birthdays, holidays), use YYYY-MM-DD format without time.
Frequently Asked Questions
What is the best date format for JSON?
ISO 8601 in UTC, such as 2026-05-17T08:30:00Z, is usually the safest choice because it is readable, sortable, and widely supported.
Should I use Unix timestamps or ISO 8601 in JSON?
Use ISO 8601 when readability and interoperability matter; use Unix timestamps when compact size or numeric comparison matters more.
Why do JSON dates cause time zone bugs?
Bugs happen when systems store local time without an offset or parse the same value differently across languages and environments.