Is 24:00 a valid ISO 8601 time?

Yes. ISO 8601 allows 24:00:00 to denote midnight at the end of a day — the same instant as 00:00:00 of the following day. The ISO 8601-1:2019 revision deprecates it in favor of 00:00, and parsers such as JavaScript's Date and RFC 3339 reject it, so avoid emitting 24:00 in new code.

What's the difference between 00:00 and 24:00 in ISO 8601?

On a given date, 00:00 is the first instant (the start of that day) and 24:00 is the last instant (the end of that day). They are 24 hours apart: 2026-05-03T24:00 is the same moment as 2026-05-04T00:00, not the start of May 3rd.

Is 18:00 a valid ISO 8601 hh:mm time?

Yes. ISO 8601 uses a 24-hour clock with a zero-padded hour, so 18:00 is valid and equals 6:00 PM. The 12-hour form “6:00 PM” is not ISO 8601.

How does ISO 8601 represent midnight?

With two notations: 00:00 (or 00:00:00) is midnight at the start of a day, and 24:00 (or 24:00:00) is midnight at the end of a day, equal to 00:00 of the next day. There is no AM/PM, so 12:00 always means noon.

ISO 8601 Cheat Sheet: Is 24:00 a Valid Time?

2026-05-03 7 min read

ISO 8601 is the international standard for representing dates and times in a way that humans and machines both understand. If you've ever stared at 2026-05-03T16:30:00Z and wondered exactly what each character means, this is for you.

I'll skip the history lesson. Here's what you actually need.

The basic date format

YYYY-MM-DD

Four-digit year, dash, two-digit month, dash, two-digit day. Always zero-padded.

2026-05-03         valid — May 3, 2026
26-5-3             not ISO 8601
2026/05/03         not ISO 8601 (slash, not dash)
2026-05-3          invalid — day must be zero-padded

The dashes are required when you write it for humans. Some systems use the compact form 20260503 (no dashes), which is also valid ISO 8601 but harder to read.

Adding a time

Glue a T between the date and the time, then write the time as 24-hour HH:MM:SS:

2026-05-03T16:30:00

The T is mandatory in strict ISO 8601. A space (2026-05-03 16:30:00) is more human-friendly but technically a different format (RFC 3339 allows it; pure ISO 8601 doesn't).

You can omit fields from the right:

2026-05-03T16:30:00     full second
2026-05-03T16:30        no seconds
2026-05-03T16           no minutes (rare)

You can also add fractional seconds:

2026-05-03T16:30:00.123          milliseconds
2026-05-03T16:30:00.123456       microseconds
2026-05-03T16:30:00.123456789    nanoseconds

HH:MM time format examples (18:00, 09:30, 23:59)

ISO 8601 times are always 24-hour. No AM/PM. Leading zeros are required on the hour.

18:00         valid — 6:00 PM
09:30         valid — 9:30 AM (leading zero required)
9:30          invalid — hour must be zero-padded
23:59         valid — one minute before midnight
6:00 PM       not ISO 8601 (12-hour clock not allowed)

So 18:00 in ISO 8601 is the same instant as 6:00 PM in 12-hour notation. The format is HH:MM for hour-minute and HH:MM:SS if you need seconds.

Is `24:00` a valid time in ISO 8601?

Yes — but only to represent the end of a day. This is one of the most-misunderstood parts of the standard.

The original ISO 8601:2004 explicitly allows 24:00:00 as a valid time notation, meaning "midnight at the end of the day" — the same instant as 00:00:00 of the next day:

2026-05-03T24:00:00     valid — end of May 3rd = start of May 4th
2026-05-04T00:00:00     same instant, different notation
2026-05-03T24:00:01     invalid — nothing after 24:00 on that date
2026-05-03T24:30:00     invalid — minutes/seconds must be 00 when hour is 24

The newer ISO 8601-1:2019 revision deprecated 24:00 in favor of always using 00:00 of the following day. Most modern parsers (JavaScript Date, Python datetime, Postgres timestamptz) reject 24:00 outright. RFC 3339 also forbids it.

Practical advice: Don't emit 24:00 in new code. If you receive it, normalize to 00:00 of the next day before further processing.

`00:00` vs `24:00`: is it the beginning or end of day?

Both notations exist precisely because the moment of midnight is ambiguous in everyday speech. ISO 8601 resolves it:

00:00:00 = the beginning of the day (the first instant)
24:00:00 = the end of the day (the last instant — equal to 00:00:00 of the next day)

So 2026-05-03T00:00:00Z and 2026-05-03T24:00:00Z are different instants on the same calendar day. The first is when May 3rd starts; the second is when it ends.

This matters in:

Billing periods: "May 3rd" usually means 2026-05-03T00:00:00Z to 2026-05-04T00:00:00Z (a 24-hour interval where the end is exclusive).
Calendar events that run "all day": start=2026-05-03T00:00:00Z and end=2026-05-04T00:00:00Z is the standard convention; some systems wrongly use end=2026-05-03T23:59:59Z and lose the last second.
Cron jobs: 00:00 triggers at midnight at the start of the date; this is almost always what people mean.

What about 12:00 — is that noon or midnight?

In ISO 8601 there is no ambiguity, because it's a 24-hour clock with no AM/PM:

12:00 = noon (midday)
00:00 = midnight at the start of the day
24:00 = midnight at the end of the day

The 12-hour-clock confusion — where "12:00 AM" means midnight and "12:00 PM" means noon, which trips up almost everyone — simply doesn't exist in ISO 8601. 12:00 is always the middle of the day.

The timezone — the part everybody gets wrong

A timestamp without a timezone is ambiguous. ISO 8601 gives you three ways to specify it:

2026-05-03T16:30:00Z          UTC (Z = "Zulu time")
2026-05-03T16:30:00+05:30     IST (5h 30m ahead of UTC)
2026-05-03T16:30:00-08:00     PST (8h behind UTC)

A few things people get wrong:

+0000 is not the same as Z in some parsers. Both mean UTC; Z is the canonical form. Use Z if you have the choice.
Offset must include a sign. +05:30, not 05:30.
The colon is allowed but not required: +0530 and +05:30 are both valid. Be consistent within your codebase.
Negative zero is allowed: -00:00 means "UTC, but the offset is unknown." +00:00 means "UTC, definitely." You'll rarely see this distinction respected.

Local time — the trap

A timestamp like 2026-05-03T16:30:00 (no timezone) is officially "local time" — meaning whatever timezone the reader assumes. Don't store these. Always include the timezone or always store UTC.

If you receive an ISO timestamp without a timezone from an API, assume nothing. Ask. Then add documentation.

Durations

Durations use a different format starting with P (for "period"):

P1Y               1 year
P2M               2 months
P10D              10 days
PT1H              1 hour (note the T separator)
PT30M             30 minutes
PT45S             45 seconds
P1Y2M3DT4H5M6S    1 year, 2 months, 3 days, 4 hours, 5 min, 6 sec
PT2H30M           2 hours 30 minutes (common for video / podcast lengths)
P7W               7 weeks

Rules:

The P is required.
The T separator is required between the date part (Y/M/D) and the time part (H/M/S). Without T, M is ambiguous between months and minutes.
Order matters: P1Y2M3D (years, months, days). You can't write P3D2M1Y.
Weeks (W) can't be combined with other units.

A duration describes a fixed length of time, but it won't tell you the resulting calendar date. When you need to add or subtract days from a specific date — accounting for month lengths and leap years — reach for a date calculator instead.

Intervals

An interval is a range with a start and end. Three formats:

2026-05-03T00:00:00Z/2026-05-04T00:00:00Z      explicit start and end
2026-05-03T00:00:00Z/P1D                       start + duration
P1D/2026-05-04T00:00:00Z                       duration + end

The slash separator is the giveaway you're looking at an interval, not a single timestamp. When you just need the length of an interval rather than its notation, computing the number of days between two dates is often all you're after.

Repeating intervals

Less common but useful for cron-like things:

R/2026-05-03T16:30:00Z/PT1H        every 1 hour starting at this time, forever
R5/2026-05-03T16:30:00Z/PT1H       repeat 5 times

The R (with optional count) prefix.

Week dates and ordinal dates

ISO 8601 also defines two alternatives to year-month-day:

2026-W18-7         year-week-dayofweek (Sunday of week 18, 2026)
2026-123           year-dayofyear (123rd day of 2026 = May 3)

Most APIs don't use these. They show up in finance, logistics, and academic contexts.

What ISO 8601 does not specify

Quarter notation (2026-Q2). Common but not part of the standard.
Year 0000 is valid — ISO 8601 uses astronomical year numbering, where 0000 represents 1 BC and -0001 represents 2 BC. Most application code rejects it, but the standard itself permits four-digit years including 0000. Years beyond four digits require an explicit +/- sign by agreement (+10000-01-01).
Time without a date. 16:30:00Z alone is technically valid ISO 8601 but most systems reject it.
Relative dates like "yesterday" or "next Tuesday". Not ISO 8601's job.
Time periods like "2 weekdays" that depend on calendar context. ISO durations are absolute.

The cheat sheet

Bookmark this:

| What | Format | Example | | --- | --- | --- | | Date | YYYY-MM-DD | 2026-05-03 | | Date + time (UTC) | YYYY-MM-DDTHH:MM:SSZ | 2026-05-03T16:30:00Z | | Date + time + offset | YYYY-MM-DDTHH:MM:SS±HH:MM | 2026-05-03T16:30:00+05:30 | | Date + time + ms | YYYY-MM-DDTHH:MM:SS.sssZ | 2026-05-03T16:30:00.123Z | | Duration | PnYnMnDTnHnMnS | P1Y2M3DT4H5M6S | | Interval | <start>/<end> | 2026-05-03/2026-05-10 | | Week date | YYYY-Www-D | 2026-W18-7 | | Ordinal date | YYYY-DDD | 2026-123 |

Practical advice

Store all timestamps in UTC. Convert to local time only at display.
Always include the timezone. Z for UTC; offset for everything else.
Use ISO 8601 in JSON APIs, not Unix timestamps as integers. Far easier to debug.
In SQL, use TIMESTAMPTZ (Postgres) or equivalent. It stores as UTC internally and converts on read.
For filenames and sortable identifiers, use the compact form: 20260503T163000Z. Lexicographic sort = chronological sort.

If you ever need to convert between formats, the Unix Timestamp Converter and Date Calculator on this site handle the common cases. To see one instant across UTC and local time zones — handling the offset and DST rules described above — use the Time Zone Converter.

When ISO 8601 isn't enough

For the rare cases where you need something it can't express:

Recurring events with specific exceptions — use iCalendar's RFC 5545 RRULE (a superset of ISO 8601).
Vague historical dates — use EDTF (Extended Date Time Format), which adds wildcards and uncertainty.
Calendar systems other than Gregorian — ISO 8601 is Gregorian-only.

For everyday work — API timestamps, log files, database columns — ISO 8601 is enough. Memorize the basic format, always include the timezone, and you'll dodge 90% of the date-handling bugs that bite production systems.

Frequently asked questions

Is 24:00 a valid ISO 8601 time?: Yes. ISO 8601 allows 24:00:00 to denote midnight at the end of a day — the same instant as 00:00:00 of the following day. The ISO 8601-1:2019 revision deprecates it in favor of 00:00, and parsers such as JavaScript's Date and RFC 3339 reject it, so avoid emitting 24:00 in new code.
What's the difference between 00:00 and 24:00 in ISO 8601?: On a given date, 00:00 is the first instant (the start of that day) and 24:00 is the last instant (the end of that day). They are 24 hours apart: 2026-05-03T24:00 is the same moment as 2026-05-04T00:00, not the start of May 3rd.
Is 18:00 a valid ISO 8601 hh:mm time?: Yes. ISO 8601 uses a 24-hour clock with a zero-padded hour, so 18:00 is valid and equals 6:00 PM. The 12-hour form “6:00 PM” is not ISO 8601.
How does ISO 8601 represent midnight?: With two notations: 00:00 (or 00:00:00) is midnight at the start of a day, and 24:00 (or 24:00:00) is midnight at the end of a day, equal to 00:00 of the next day. There is no AM/PM, so 12:00 always means noon.