How to Read TX and TN Temperature Groups in a TAF
Phase 1: Meaning, scope, and the central distinction
A Terminal Aerodrome Forecast (TAF) describes expected weather at an aerodrome during a stated validity period. In some TAF formats, temperature groups add a forecast maximum or minimum temperature and the UTC time at which that value is expected. The prefixes identify which is which: TX means maximum temperature, and TN means minimum temperature. These are temperature groups—not wind groups and not change-indicator lines. [1]
Consider TX22/1718Z. Read it as a forecast maximum of 22°C expected on the 17th at 1800 UTC. The time is the forecast occurrence time for the temperature extreme; it does not mean that a new set of weather conditions begins at 1800 UTC. IVAO’s example, TN11/1810Z, similarly represents a forecast minimum of 11°C on the 18th at 1000 UTC. [1]
That distinction is the core of decoding these groups. A TX or TN group pairs a temperature value with a timestamp. It does not describe wind direction or speed, and its timestamp does not create a forecast period. A reader or software system that treats the group as a wind field or a change window has assigned the information the wrong meaning.
A TX or TN group pairs a temperature value with a timestamp. It does not describe wind direction or speed, and its timestamp does not create a forecast period.
Phase 2: Syntax and a reliable reading workflow
The examples use a compact pattern:
TX17/0721Z
TN08/0812ZRead each token in two parts, using the slash as the boundary between temperature and time:
TX17 / 0721Z
│ │ └── Day 07, hour 21 UTC
│ └─────── Forecast temperature: 17°C
└───────── TX = forecast maximumA dependable manual workflow is:
- Identify the prefix.
TXindicates a maximum;TNindicates a minimum. - Read the temperature before the slash. In
TX17/0721Z, the value is 17°C. - Read the timestamp after the slash. The first two digits give the day of the month; the next two give the UTC hour. In this example,
0721Zmeans day 7 at 2100 UTC. - Keep the time in UTC. The
Zdenotes UTC, not local time. TAF validity times are also expressed in UTC, so a reader should not silently convert the group’s hour to local time or compare it with local clock time without making the conversion explicit. [1] - Treat the result as a forecast extremum at a time. Do not interpret it as a duration, a prevailing condition for all following hours, or the start of a new forecast window.
The same pattern, applied to TX17/0721Z and TN08/0812Z, reads as a maximum of 17°C on the seventh at 2100Z and a minimum of 8°C on the eighth at 1200Z. [1] The hour is a two-digit UTC hour, not a minute-level timestamp. Read the day and hour in the context of the TAF’s validity dates; the group itself does not provide a local-time conversion. [1]
This point-in-time interpretation matters when reading a full TAF. Other groups describe different kinds of information. Wind groups encode direction and speed. Change groups such as FM or TEMPO describe changes to forecast conditions or periods during which specified conditions are expected. The IVAO decode of a sample TAF places TX22/1718Z and TN11/1810Z beside TEMPO and FM groups, which mark forecast windows rather than a single temperature-occurrence time. [1] The temperature group is not an instruction to replace the prevailing forecast at that hour; it identifies the expected maximum or minimum and its associated time.
A common parsing error is to treat every timestamp in a TAF as a period boundary. That approach fails here: the slash separates the temperature from its occurrence timestamp, and the timestamp does not by itself define a period. For human readers, the practical check is simple: if the token begins with TX or TN, ask “which temperature extreme, and when is it forecast?” rather than “what conditions start now?”
Phase 3: Format differences and method comparison
Whether TX and TN appear depends on the TAF product format. The available guidance distinguishes ICAO-style TAFs, which can include these temperature groups, from U.S. domestic National Weather Service TAFs, which generally do not provide temperature forecasts in this form. Therefore, the absence of TX and TN in a domestic U.S. TAF is not, on its own, evidence that the forecast is incomplete or malformed. [2]
This is a useful distinction between reading a group and validating a product. If TX or TN is present, interpret its value and timestamp according to the group’s structure. If it is absent, first consider the format and source of the TAF rather than assuming that the message is defective. Aviation Weather Center documentation also covers temperature groups in aviation weather-code material; those formats should not be transferred automatically to a TAF without checking which product is being read. [2]
For software, the equivalent discipline is to identify the product type before applying format-specific validation rules. A parser intended for one regional TAF feed may not encounter every group used in another format. A robust design should therefore distinguish “not expected in this product profile” from “invalid token,” while still interpreting recognized TX and TN groups correctly where they are supported.
VectorWX (https://vectorwx.app) is one place where a reader can practice comparing TAFs from more than one source or format. [3] In such a workflow, the relevant methodological question is whether the parser preserves a TX or TN value as a temperature extremum with a UTC occurrence time, rather than classifying it as wind data or a change group. This is an example of a validation requirement, not a claim about any specific VectorWX system or test result.
Phase 4: Operational interpretation and longer-term data handling
A forecast maximum or minimum can add useful temperature context to an aerodrome forecast, but it should not be treated as a complete performance calculation or as a substitute for reading the rest of the TAF. The group supplies a temperature value and a forecast time. It does not, by itself, provide every input needed to determine aircraft performance or establish what the prevailing weather will be throughout the forecast period.
For operational use, retain the two pieces of information together: the value and the UTC time. Converting TX22/1718Z into “22°C” while discarding 1718Z loses part of the forecast. Conversely, retaining only the timestamp risks confusing the group with a change window. A system that displays or stores the data should label the temperature as a forecast maximum or minimum and preserve its date-and-hour context.
The same distinction applies as aviation weather distribution evolves. Compact alphanumeric TAFs require readers and parsers to infer meaning from short tokens and their position. More structured data representations can make a value and its associated time easier to represent as separate fields. Regardless of the delivery format, however, the semantic relationship remains the same: TX or TN identifies a forecast temperature extreme, and its timestamp identifies when that extreme is expected. Correct interpretation begins with preserving that relationship rather than treating the token as a wind field, a change indicator, or a continuous time window.