What does an ISO 8601 timestamp without a timezone mean?

ISO 8601 gives a time three possible endings: Z for UTC, an offset like +02:00, or nothing. The standard calls the third form local time. It is a floating value that describes what a clock on a wall reads, with no way to recover which wall. 2026-06-01T11:10:52 is ten past eleven in the morning somewhere. In London that is 10:10:52Z, in New York 15:10:52Z and in Tokyo 02:10:52Z, and the string cannot tell you which.

That is fine for a recurring alarm or a calendar entry that should stay at 9am when its owner travels. It is wrong for a log line, a payment or anything that has to line up with another system.

Each language picks its own default. JavaScript's Date reads 2026-06-01T11:10:52 as local time but reads the date-only form 2026-06-01 as midnight UTC, so the two shapes differ by your offset. On a machine set to New York, new Date("2026-06-01T11:10:52") is 15:10:52Z while new Date("2026-06-01") is 00:00:00Z. Python's datetime.fromisoformat returns a naive datetime, and ordering a naive value against an aware one raises a TypeError. PostgreSQL stores a zone-less value unchanged in a timestamp column and applies the session timezone when you cast it to timestamptz. Java's LocalDateTime refuses to become an Instant until you supply a zone.

None of these are bugs. Each is a different answer to a question the string left open.

Emit the zone every time a timestamp leaves a process. Z is shortest: 2026-06-01T11:10:52Z. An offset is right when the local reading matters, as in 2026-06-01T11:10:52+02:00. In JavaScript, new Date().toISOString() always ends in Z. In Python, datetime.now(timezone.utc).isoformat() ends in +00:00. On the command line, date -u +%Y-%m-%dT%H:%M:%SZ prints UTC with the Z. Store UTC in the database and convert for display.

If you receive a zone-less value you cannot change, decide its zone at the boundary where it enters your system, write that decision down, and attach the offset before the value goes any further.

parsetime reads 2026-06-01T11:10:52 in your browser's timezone and shows a note under the result: no timezone in the input, so it's read as your local time. The detected format is listed as ISO 8601 with no timezone. If the value was meant to be UTC, add a Z and paste it again. The API takes the other default: it reads zone-less input as UTC unless you pass ?tz= with the zone you mean. A date-only value like 2026-06-01 is read as midnight UTC, the way JavaScript does it, and the note says that too. You never have to guess which reading you got.

The ISO 8601 converter handles the full format, and the date to Unix timestamp page turns a local reading into an epoch value.