The current instant, in ISO 8601
2026-08-12T23:25:07Z
with ms 2026-08-12T23:25:07.549Z
·
basic 20260812T232507Z
·
week 2026-W33-3
Device clock: checking…
ISO 8601 is the format that sorts as a string, parses everywhere and cannot be misread across locales. Here is the current value, the grammar behind it, and the exact line where ISO 8601 and RFC 3339 disagree.
The grammar, field by field
| Field | Example | Rule |
|---|---|---|
| YYYY | 2026 | Four-digit year, zero padded. |
| MM | 01 | Month 01-12. |
| DD | 01 | Day of month 01-31. |
| T | T | Literal separator between date and time. |
| hh | 12 | Hour 00-23. 24:00:00 is legal as end-of-day only. |
| mm | 00 | Minute 00-59. |
| ss | 00 | Second 00-60 — 60 exists for leap seconds. |
| .sss | .123 | Optional fractional seconds, any precision. |
| Z or ±hh:mm | Z | UTC designator or explicit offset. |
Valid and invalid
Valid
| 2026-01-01T12:00:00Z | Date, time and UTC designator. The safest form. |
| 2026-01-01T12:00:00+05:30 | Explicit offset, including half-hour zones. |
| 2026-01-01T12:00:00.123Z | Fractional seconds — any number of digits is legal. |
| 2026-01-01 | Calendar date alone. |
| 2026-W01-4 | ISO week date: week 1, Thursday. |
| 2026-001 | Ordinal date: day 1 of 2026. |
| 20260101T120000Z | Basic format, no separators. Valid ISO 8601, NOT RFC 3339. |
| P1Y2M3DT4H5M6S | A duration, not an instant. ISO 8601 only. |
Invalid or unsafe
| 2026-1-1T12:00:00Z | Months and days must be zero-padded to two digits. |
| 2026-01-01 12:00:00 | A space instead of T is tolerated by some parsers; not portable. |
| 2026-01-01T12:00:00 | No offset — the instant is ambiguous. RFC 3339 rejects it. |
| 2026-01-01T12:00:00Z+05:00 | Z and an offset are mutually exclusive. |
| 01/01/2026 | Not ISO 8601 at all, and ambiguous between US and UK reading. |
| 2026-01-01T24:00:01Z | Hour 24 is only legal as exactly 24:00:00, meaning midnight ending the day. |
ISO 8601 vs RFC 3339 the interview question, settled
| Feature | ISO 8601 | RFC 3339 |
|---|---|---|
| Uppercase T separator | Required (basic format aside) | Required, though lower-case t is tolerated |
| UTC offset | Optional | Mandatory |
| Z designator | Allowed | Allowed, plus -00:00 meaning "offset unknown" |
| Week dates (2026-W01-1) | Allowed | Not allowed |
| Ordinal dates (2026-001) | Allowed | Not allowed |
| Basic format (20260101T120000Z) | Allowed | Not allowed |
| Durations and intervals | Defined by the standard | Out of scope |
| Years before 1583 | By mutual agreement | Not allowed |
| Fractional seconds | Any number of digits | Any number of digits |
Rule of thumb: RFC 3339 is the strict subset you should emit; ISO 8601 is the looser superset you have to be able to read.
Parse and format it in code
Python
from datetime import datetime, timezone
# format
datetime.now(timezone.utc).isoformat() # '2026-01-01T12:00:00+00:00'
# parse (3.11+ accepts the trailing Z)
datetime.fromisoformat('2026-01-01T12:00:00Z')JavaScript
// format
new Date().toISOString(); // '2026-01-01T12:00:00.000Z'
// parse
new Date('2026-01-01T12:00:00Z');
// NB: Date.parse of a date-only string ('2026-01-01') is UTC,
// but '2026-01-01T00:00:00' (no zone) is LOCAL. Always send an offset.Go
t, err := time.Parse(time.RFC3339, "2026-01-01T12:00:00Z")
s := t.UTC().Format(time.RFC3339) // Go's RFC3339 == the ISO 8601 profileJava
import java.time.*;
import java.time.format.DateTimeFormatter;
OffsetDateTime t = OffsetDateTime.parse("2026-01-01T12:00:00Z");
String s = t.format(DateTimeFormatter.ISO_OFFSET_DATE_TIME);Rust
use chrono::{DateTime, Utc};
let t: DateTime<Utc> = "2026-01-01T12:00:00Z".parse().unwrap();
let s = t.to_rfc3339();PHP
$t = new DateTimeImmutable('2026-01-01T12:00:00Z');
echo $t->format(DATE_ATOM); // RFC 3339 / W3C profileSQL — PostgreSQL
SELECT '2026-01-01T12:00:00Z'::timestamptz; -- parses ISO 8601 natively
SELECT to_char(now() AT TIME ZONE 'UTC', 'YYYY-MM-DD"T"HH24:MI:SS"Z"');Bash
date -u -d '2026-01-01T12:00:00Z' +%s # parse to epoch
date -u -d @1767268800 --iso-8601=seconds # epoch to ISO 8601ISO 8601 questions
What is ISO 8601?
The international standard for writing dates and times as text: biggest unit first, zero-padded, with an explicit UTC offset. 2026-01-01T12:00:00Z is unambiguous in every locale, sorts correctly as a plain string, and parses in every mainstream language.
What is the difference between ISO 8601 and RFC 3339?
RFC 3339 is a narrower profile of ISO 8601 built for internet protocols. Almost everything valid in RFC 3339 is valid ISO 8601, but not the reverse: ISO 8601 also allows week dates (2026-W01-1), ordinal dates (2026-001), basic format with no separators (20260101T120000Z) and durations (P1Y2M3D), none of which RFC 3339 accepts. RFC 3339 requires an offset, ISO 8601 lets you omit it. If you are writing JSON, aim for RFC 3339 and you are also writing valid ISO 8601.
Does the T have to be there?
In RFC 3339 the separator may be a lower-case t or a space by mutual agreement, but a literal uppercase T is what every parser accepts without argument. ISO 8601 permits dropping it only in the basic format. Keep the T.
What does the Z mean?
Zero offset from UTC — the "Zulu" designator from military time. 2026-01-01T12:00:00Z and 2026-01-01T12:00:00+00:00 denote the same instant. RFC 3339 also defines -00:00 to mean "UTC, but the local offset is unknown", a distinction most libraries silently discard.
How many decimal places can the seconds have?
ISO 8601 puts no limit on fractional-second digits, which is a common interoperability bug: JavaScript emits exactly three, Python emits six, Go emits as many as it needs and trims trailing zeros, and some parsers reject anything other than three. If you control both ends, standardise on three or six and say so in your API docs.
Is 2026-01-01 alone valid ISO 8601?
Yes, as a calendar date. The trap is what happens when a datetime parser reads it: JavaScript treats a date-only string as UTC midnight but a date-and-time string with no offset as LOCAL midnight, so adding a time to the string can move the value by hours.