title: ISO 8601 Formatter: Generate & Validate Any Date intro: Most people assume ISO 8601 always looks like 2026-01-15T14:30:00Z. It doesn't. The standard permits two forms, and the Z means something very specific. Here is how to generate and validate any date correctly, right now.

Current Date in ISO 8601 Extended and Basic Formats

You have two legal ways to write the same moment. The extended format uses hyphens and colons: 2026-10-01T14:30:00+02:00. The basic format drops every separator: 20261001T143000+0200. Both are fully compliant with ISO 8601.

Use the extended format for APIs, logs, and human-readable output. Use the basic format when you need to save space or when a system demands it. Some file formats and database keys prefer the compact form. Most modern libraries in JavaScript, Python, and Java output the extended form by default. Choose that unless you have a specific reason not to.

What Does the T and Z Mean in an ISO 8601 Formatter Output?

The T separates the date from the time. It is not optional in the standard's strictest reading. ISO 8601-1:2019 discourages using a space instead, even though older versions allowed it.

The Z is not a general "this is UTC" marker. It means UTC+00:00 exactly. If your offset is +02:00, you write +02:00, never Z. Many developers assume Z means "UTC" loosely, but the standard defines it as the zero offset specifically. When you see 2026-10-01T12:00:00Z, that instant is 14:00 in a zone at +02:00. The Z is a fixed value, not a catch-all.

How an ISO 8601 Formatter Handles Your UTC Offset

Your local time without an offset is not ISO 8601 compliant for a specific instant. If you live in a zone at UTC+5:30, you must write 2026-10-01T19:45:00+05:30. The offset uses ±hh:mm in extended format or ±hhmm in basic format.

Do not skip the offset. A datetime like 2026-10-01T14:30:00 is ambiguous. It could be any zone on Earth. That is why the standard requires the offset or the Z. When you generate a timestamp from your code, always include the offset. If you are storing a past event, convert to UTC first and append Z. That is the safest practice, and it is the one major databases and APIs expect.

ISO 8601 Week Dates and Ordinal Dates

Two formats in the standard trip people up because they rarely appear in everyday tools.

Week dates look like 2026-W30-2. That is the year, the week number (W30), and the day of the week (2 = Tuesday). ISO 8601 week 1 is the week containing the first Thursday of the year. This means the week-numbering year can differ from the calendar year. December 29, 30, or 31 can fall in week 1 of the next year. January 1, 2, or 3 can belong to the last week of the previous year. Most software does not output this format, but it is part of the standard and appears in supply chain, payroll, and manufacturing contexts.

Ordinal dates look like 2026-274. That is the year followed by the day of the year, from 001 to 365 (or 366 in a leap year). October 1 is day 274 in a non-leap year. This format appears in some satellite data and logistics systems. It is unambiguous and compact, but you rarely need to write it by hand.