Reading and Writing Military Time

Military time is not simply the 24-hour clock

Most of the world already writes 14:30 and calls it the time. That is the 24-hour clock, and it is ordinary civil notation across Europe, Latin America and much of Asia. American military time is a narrower thing built on top of it: the colon is dropped, the hour is always padded to two digits, the result is read as a single four-digit group, and a letter identifying the time zone is appended. 14:30 becomes 1430; spoken, it is “fourteen thirty”; written in full for a signal, it is 1430R or 1430Z depending on the zone the time is expressed in.

The spoken form is where the two genuinely part company, and the converter shows it on every result. On the hour, the last two digits are read as a hundred and the word “hours” is added: 0800 is “zero eight hundred hours”, 1200 is “twelve hundred hours”, 2300 is “twenty-three hundred hours”. Off the hour, “hours” disappears and the minutes are named: 1430 is “fourteen thirty”, 2115 is “twenty-one fifteen”. Below ten, the hour keeps its spoken zero — “zero nine hundred hours”, not “nine hundred hours”.

One honest note about the tool's spoken output: for minutes under ten it uses “oh” — 0905 comes back as “zero nine oh five”. That is the common civilian habit and you will hear it, but the strict radio form is “zero niner zero five”, with every digit named and “niner” substituted for “nine” so it cannot be confused with “five” over a poor channel. The converter does not use the phonetic digit substitutions at all. If you are writing a script for someone to read aloud on a net, spell the digits yourself.

Midnight is 0000, and the argument about 2400

A day has two midnights on its edges and only one set of four digits to name them with, which is the whole problem in one sentence. The convention that works is to treat 0000 as the midnight that opens a date and 2400 as the midnight that closes it — the same instant, two labels, and which one you write says which day you mean. NIST states both explicitly in its guidance on times of day, and recommends the 24-hour clock precisely because it can make the distinction that a.m. and p.m. cannot.

The converter documents this and then does not implement it. Its own closing note tells you that midnight is written 0000, that 2400 is sometimes used for the end of the day, and that 0000 is the recommended form. Type 2400 into it and it answers that the time is invalid: the parser accepts hours 0 to 23 and minutes 0 to 59 and nothing else, so 2359 is the last value it will take. Nothing is computed wrongly — there is simply a gap between the footnote and the input. If you need to record an end-of-day boundary, write it as 2359 with the understanding that it is a minute short, or use a date-and-time format that can express the boundary properly.

Why 12-hour notation cannot settle noon

The abbreviations are Latin: ante meridiem, before noon, and post meridiem, after noon. Noon itself is neither before nor after noon, so neither suffix can honestly be attached to it, and midnight is twelve hours before noon and twelve hours after it at once. NIST puts this plainly: 12 a.m. and 12 p.m. are ambiguous and should not be used. It is not a pedantic point — a lease that expires at 12 a.m. on the first of the month is a genuine dispute waiting to happen, and NIST's own suggestion for legal documents is to write 11:59 p.m. or 12:01 a.m. and remove the question.

The converter's twelve-hour side handles the two cases correctly, which is worth checking on any tool you use. 12:00 AM maps to 0000 and 12:00 PM maps to 1200 — not the other way round, which is the classic off-by-twelve. It gets there by a small rule rather than a table: the hour 12 is treated as 0 first, and then twelve is added if the half is PM. That is why 12:30 AM comes out as 0030 and 12:01 PM as 1201.

What ISO 8601 allows, and what RFC 3339 forbids

The international standard resolves the midnight problem by allowing hour 24, but only as an end-of-day marker. 2026-08-28T24:00 is the instant that closes 28 August, and it names the same moment as 2026-08-29T00:00 while pointing at a different date. There is no 24:01, and no other hour goes above 23. That is the whole concession, and it exists because a shift, a billing period or a legal deadline that ends at midnight belongs to the day that is ending, not to the one starting.

The internet's profile of that standard goes the other way. RFC 3339, which is what almost every API timestamp actually conforms to, restricts the hour to 00–23 and says why in one line: although ISO 8601 permits the hour to be 24, this profile allows only 00 to 23 in order to reduce confusion. So the same timestamp is legal in one document and rejected in the other, and a system that round-trips through a JSON API will silently turn your end-of-day into the next day's start. If you are storing a boundary, store the instant and record separately which day it belongs to; do not rely on the notation to carry that meaning through a parser you did not write.

The zone letters, and the date they hide

Every whole-hour offset from UTC has a letter. Z is Zulu, UTC itself; A through M walk east, one hour each, skipping J; N through Y walk west. J — Juliett — is reserved for the observer's own local time and carries no fixed offset, which is why the converter lists twenty-five letters and leaves J out of the table. The suffix is not decoration: 1430 without a letter is a time in an unstated zone, and the point of the notation is that a message read in three countries means one instant.

Two limits follow from the letters being whole hours. Zones on a half-hour or quarter-hour offset — India at UTC+5:30, Nepal at UTC+5:45, parts of Australia at UTC+9:30 — have no letter at all, and any notation that forces one on them is wrong. And summer time is not in the letter either: the same place in Paris is A in winter and B in summer, so a letter written down in March may name the wrong offset by June.

There is one thing the converter's Zulu line does not tell you, and it matters more than the arithmetic. Converting an hour across a zone boundary can change the date, and the tool reports only the hour. Take 0030A, half past midnight at UTC+1: the correct answer is 2330Z, but on the previous day. Take 2330R, half past eleven at night at UTC−5: the correct answer is 0430Z, on the following day. The converter prints 2330Z and 0430Z and says nothing about which day either belongs to. Whenever the conversion crosses midnight in either direction, work the date out yourself before you write it down.

Frequently asked questions

How do you actually say 0800 out loud?

“Zero eight hundred hours.” On the hour, the last two digits become “hundred” and the word “hours” is added; below ten, the leading zero is spoken. So 0900 is “zero nine hundred hours”, 1000 is “ten hundred hours” and 2300 is “twenty-three hundred hours”. Off the hour, “hours” disappears and you simply name the minutes: 1430 is “fourteen thirty”, 2115 is “twenty-one fifteen”. Midnight is the odd one, spoken “zero hundred hours”, and 0030 comes out as “zero zero thirty”.

Is midnight 0000 or 2400?

Both, and which you write says which day you mean. NIST's guidance sets it out: 0000 is the midnight that begins a date and 2400 is the midnight that ends it — the same instant, two labels for two purposes. In practice 0000 is the safer default because more systems accept it; ISO 8601 permits 24:00 only as an end-of-day marker, and RFC 3339, which most APIs follow, forbids it outright. This converter takes 0000 and rejects 2400, so if you need to record an end-of-day boundary here, use 2359 and note that it is a minute early.

What is the letter on the end, and what does Z mean?

It names the time zone the four digits are expressed in. Z is Zulu, which is UTC; A to M run east from UTC+1 to UTC+12, skipping J; N to Y run west from UTC−1 to UTC−12. J — Juliett — means the observer's own local time and has no fixed offset, which is why it is not in the tool's table. Only whole-hour zones have letters, so India at UTC+5:30 and Nepal at UTC+5:45 have none, and the letter does not encode summer time: Paris is A in winter and B in summer.

Is military time the same as the 24-hour clock used in Europe?

Same clock, different notation and different speech. A French, German, Spanish, Portuguese or Italian speaker writes 14:30 with a colon and says it in their own language — quatorze heures trente, vierzehn Uhr dreißig, las catorce treinta. The US military writes 1430 with no colon, says “fourteen thirty”, and appends a zone letter that civil notation does not carry. The converter shows both, which is the fastest way to see that the difference is a convention layered on top and not a different way of dividing the day.

Does the converter handle the date change when it converts to Zulu?

No. It converts the hour correctly and says nothing about the day, which is the one place it can quietly mislead you. 0030A becomes 2330Z — but on the previous date. 2330R becomes 0430Z — on the following one. 0800M, at UTC+12, becomes 2000Z on the day before. The arithmetic is right in every case; the calendar is simply absent from the output. Any time the conversion crosses midnight, write the date down yourself, and prefer a full date-and-time format over a bare four digits plus a letter when the message has to survive being read tomorrow.