SDIF

From Libre Aquatics Wiki, the free aquatics reference

SDIF, the Standard Data Interchange Format, is the record layout United States Swimming published so that swimming entries, results and registration data could move between programs, and from meet hosts up to the governing body, without being retyped. A file is plain text, carries the extension .sd3, and is built from fixed-length records that each begin with a two-character code naming the record type.¹ Version 3, dated 28 April 1998, is the last version published, and it is still what current meet-management software writes.

Form¶

Every record occupies 162 bytes. The first 160 carry data, byte 161 is a carriage return and byte 162 a line feed, so the file is a text file of fixed-width lines and a reader can treat it either as a byte stream or line by line.¹ A results file written in 2026 is 148,230 bytes, which divides into 915 records with nothing left over, and every one of those records ends in the two terminator bytes.²

Fields are addressed by a start position and a length, counted from one, and the specification writes them in that form, so the swimmer name on an individual event record is 12/28. This page follows that convention. It is not the convention used on the HY3 page, where columns are numbered from zero, and the two should not be read against each other without allowing for the difference.

Eleven field types are declared. CONST is a fixed literal, and the two bytes that open every record are always CONST and case sensitive. A CODE field has to correspond exactly to an entry in one of the tables printed at the end of the document, and case matters there too. ALPHA holds text, left justified, except that a field containing only digits is right justified instead. INT and DEC are ASCII digits, right justified and blank filled, with DEC allowing a decimal point. DATE is eight characters as MMDDYYYY, with no blanks permitted anywhere in a date that is supplied. TIME is either blank, or minutes, seconds and hundredths in the shape mm:ss.ss, or a code. A LOGICAL field accepts three things only: a capital T, a capital F, or nothing. PHONE, USPS and USSNUM cover telephone numbers, postal state abbreviations and swimmer registration numbers.¹

Fields carry one of two levels of obligation, not a single flag. An M1 field has to carry a non-blank value for its record to be worth anything. An M2 field is one United States Swimming needs in order to process the record, and a blank one is supposed to raise an exception report rather than simply pass. Space that the format does not yet use is marked for future use and has to be left blank until it is defined.¹

SDIF records carry no checksum. The word appears once in the whole specification, in its list of revisions, which records that the checksum fields were taken out and their space reserved.¹ That is the sharpest structural difference from the two Hy-Tek formats that travel alongside it: an HY3 line ends in a two-character checksum and a CL2 line in a four-character one, and a reader is expected to verify them, while nothing in an SDIF record verifies itself.

Only two record types are required. A file opens with an A0 and closes with a Z0, and everything between them is optional, so a file carries the record types its purpose calls for and omits the rest.¹ The 2026 results file bears that out: it holds A0, B1, C1, D0, D3, E0, F0, G0 and Z0 records and no others, with no B2, C2, D1, D2 or J records at all.²

The records¶

Sixteen record types are defined.¹

Code	Record
`A0`	File description: what the file is, who made it and with what software
`B1`	Meet name, address and dates
`B2`	Meet host contact details
`C1`	Team identification
`C2`	Team entry totals and contact
`D0`	An individual swim: the athlete, the event and the times
`D1`	Individual administrative data
`D2`	Individual contact details
`D3`	Individual information, including the newer registration number
`E0`	A relay entry or result
`F0`	A swimmer making up a relay
`G0`	Splits
`J0`	Meet qualifying times
`J1`	National age group times
`J2`	Motivational times
`Z0`	File terminator, with record counts

The ordering carries meaning. The format puts the data that occurs once ahead of the data that repeats, so one meet precedes many teams, which precede many swimmers, which precede many swims. Records are tied together either by shared field values or simply by the order they appear in, which is why a D0 that is not preceded by proper team records is taken to belong to whichever team was identified last.¹

Code tables¶

Roughly two dozen tables sit at the back of the document and a CODE field has to match one of them exactly. They cover the organization (1 for United States Swimming, 2 for Masters, 3 for NCAA, 7 for YMCA, 8 for the international federation, 9 for high school), the file type (01 for meet registrations, 02 for meet results, and others for record and time standard files), the three-letter country codes, the meet type, sex, stroke, course, attached status, split type, region, zone, ethnicity and more.¹

Two of the tables are built by rule instead of being listed out. An event age code is four characters, the lower age limit in the first two and the upper in the last two, with UN standing for no lower limit and OV for none at the top, so an open event reads UNOV. An event time class code is two characters assembled the same way, the first marking the bottom of the range and the second the top, drawn from the novice, B, BB, A, AA, AAA, AAAA, junior and senior standards.¹

Course codes allow either digits or letters for the same three pool types, on the stated grounds that the letters make a file easier to read: short course metres is 1 or S, short course yards 2 or Y, and long course metres 3 or L. A fourth value, X, marks a disqualification, which is not a pool type at all.¹

A record read¶

The records below are invented but well formed. The swimmer and the club do not exist, and the identifier is constructed rather than issued, but each line is 160 characters and every field sits where the specification puts it, so they can be counted against the tables above. The swimmer is the same invented one used on the HY3 page, so the two sets of examples can be compared directly.

A file description record, A0:

A01V3      02                              Riverside Timing    2.1       Marguerite Wren     3085550142  02142026                                          NE

Start/length	Field	Value
1/2	Record code	`A0`
3/1	Organization	`1`
4/8	SDIF version	`V3`
12/2	File type	`02`
44/20	Software name	`Riverside Timing`
64/10	Software version	`2.1`
74/20	Contact name	`Marguerite Wren`
94/12	Contact phone	`3085550142`
106/8	File created	`02142026`
156/2	Submitting body	`NE`

An individual event record, D0, for a 500 yard freestyle swum from lane 5 of heat 3 and won in the final:

D01        Wren, Marguerite D          082692MARAWRAUSA0826199222FF 5001  9 UNOV02142026 4:38.67Y 4:36.99Y          4:34.12Y 3 5 1 4  1  120.0

Start/length	Field	Value
12/28	Swimmer name	`Wren, Marguerite D`
40/12	Registration number	`082692MARAWR`
52/1	Attached	`A`
53/3	Citizenship	`USA`
56/8	Date of birth	`08261992`
66/1	Sex	`F`
68/4	Distance	`500`
72/1	Stroke	`1`
77/4	Event age range	`UNOV`
81/8	Date of swim	`02142026`
89/8	Seed time	`4:38.67`
98/8	Prelim time	`4:36.99`
116/8	Final time	`4:34.12`
125/2, 127/2	Prelim heat and lane	`3`, `5`
133/3, 136/3	Prelim and final place	`1`, `1`
139/4	Points	`20.0`

Each of the three time fields is followed by a one-character course code, mandatory whenever the time before it is filled, which is how a file can carry a yards seed time against a metres final without ambiguity.¹

Splits for that swim ride in a separate G0 record, cumulative in this case, with ten time fields and the split distance stated once:

G01            Wren, Marguerite D          082692MARAWR110  50C   24.51   51.85 1:19.40 1:46.93 2:14.44 2:42.23 3:10.50 3:39.31 4:08.26 4:36.99

Ten time fields is the limit of one record, so a longer swim runs onto further G0 records numbered by the sequence field at 56/1. In the 2026 file every one of the 407 splits records is cumulative at a 50-unit split distance, and the arithmetic is exactly what the design implies: the eleven swims carrying 33 splits each occupy four records, producing 44 records that declare a 33 total and eleven each of sequence numbers 2, 3 and 4.²

What a real file shows¶

The specification establishes what a file may contain. A file written nearly three decades later shows which parts of it survived.²

The version field added in version 3 still reads V3, so a file produced in 2026 declares the 1998 format unchanged. The software version field beside it reads 0.1 Alpha, which is what the writing program puts there in ordinary production output.

The terminator record declares how many records of each letter the file holds, and those counts can be checked. Four of them are exactly right. The count for D records is not: the file holds 329 records beginning with D, being 272 D0 and 57 D3, and the terminator declares 272, while the adjacent field for the number of different swimmers reads 57. The writer is therefore counting only individual event records as D records and using the D3 total as its swimmer count. The specification does not say in terms whether a D3 counts toward the D total, so this is best read as an interpretation of an underspecified field rather than a defect.

The registration number is the clearest case of a 1998 format being stretched. The specification defines the constructed identifier as a date of birth followed by three letters of the first name, the middle initial and four letters of the surname, with asterisks padding anything too short, which comes to fourteen characters.¹ The USS# field on the D0 record is twelve bytes. That mismatch is why version 3 added the D3 record with a fourteen-byte field of its own, rather than widening D0 and displacing every field after it. USA Swimming has since moved to an opaque fourteen-character identifier, and the squeeze is unchanged: in the 2026 file all 57 D3 records carry the full fourteen characters, and in all 57 cases the D0 in front of them carries the first twelve of the same value with the last two dropped. Hy-Tek’s own HY3 gives that field fourteen columns and so loses nothing, which is one concrete respect in which the proprietary format outgrew the published one.

Eight individual event records in the file carry a stroke code of H, with a distance of 1 or 3 and a finals figure between 193 and 345. The stroke table runs from 1 to 7 and has no H in it. Taken together with the board heights and the size of the numbers, these are diving results, carried through a code the specification never defines and with the judges’ score sitting in a field meant for a time. No published definition of the code was found. This is an observation from a single file rather than a documented extension, and it should be confirmed against others before it is relied on.

Versions¶

United States Swimming set up an ad-hoc committee to establish what was needed and draft the design, and credits two outside contributors with shaping what came out of it: someone representing US Masters Swimming, along with a coach who understood what high school and college programs required. The format was meant to be extensible, by adding records or by adding codes and fields to existing ones, and to be usable by aquatic sports bodies beyond swimming.¹

Versions 1 and 2 have not been found published, and what can be said about them comes from version 3 describing its own changes. The D3 record exists to carry information the earlier formats had no room for, which is the document stating plainly that earlier formats existed.¹ The revision lists record the removal of an H0 record, of vendor-defined fields, of a transaction field, of one of the code tables and of the checksum fields, and the addition of the D3 record, the version-number field on A0, the LOGICAL type, an ethnicity table, and the definition of the .sd3 extension itself. That last item explains why the extension turns up in no vendor document older than this one: it was named during version 3 rather than before it.

Swim Data attributes the move to version 3 to the change in how swimmers were identified, and separately points out that the constructed number carries only a two-digit year and so is not safe across the century boundary.³ The first of those is consistent with what the revision lists show, but it is that site’s reading rather than the specification’s own account, and the site does not name its author.

No revision later than April 1998 was found.

Adoption¶

The format was in circulation well before the version 3 document. In December 1994 United States Swimming told readers of Swimming World that results could reach each LSC’s Top 16 tabulators on disk or by modem as more vendors adopted the format, that this removed the retyping and the errors it introduced, and that anyone whose vendor did not yet support it should ask when it would.⁴ That is three and a half years before the version 3 document is dated.

Publication did not clear the field. In May 1998, the month after version 3 was dated, Swimming World was still asking for times either in an SDIF-compatible format or in Hy-Tek’s Commlink, so the open standard and the proprietary route ran side by side.⁵ Hy-Point Software advertised its SwimMeet Manager as fully compliant with the standard in a run of advertisements from at least September 2000 into January 2001, which shows compliance being sold on and not simply assumed.⁶ Hy-Point is a different company from Hy-Tek, and the two are easily confused.

The reach was not only American. SwimNews, published in Canada, launched a searchable world ranking database in November 2001 and asked for results as SDIF or Commlink data.⁷ By the middle of 2002 a meet-management program was advertising in the same magazine that it read entries in Commlink, SDIF, WSV, Lenex and Aquabec and wrote results in most of the same set, which places SDIF as one interchange format among several rather than the only one.⁸

Results were never the whole of it. The format was designed to carry registration data up to the governing body as well, and it still does: an LSC procedure for electronic athlete registration names the three formats a club’s software has to be able to produce for USA Swimming’s SWIMS database as SDIF version 3, Hy-Tek’s CL2, and XSDIF, an XML form carried in .xml files, and has the club registrar email a zipped SDIF file to the registration chair.⁹ That document calls CL2 by the name COM Link, which is the same name Hy-Tek gave its earlier diskette exchange.

It is still in use. The file examined for this page was written in 2026, twenty-eight years after the specification it conforms to.²

Where it sits¶

SDIF is the published standard that Hy-Tek’s formats are measured against rather than a format Hy-Tek owns. CL2 is close to it and not the same: a CL2 line is 160 characters, uses SDIF’s record codes, and ends in a checksum that SDIF does not have, which is why converting between them takes a utility and not a rename. Meet Manager provides that utility, converting a CL2 export to SDIF and naming the output after the database and a sequence number.¹⁰ HY3, the newer of the pair Hy-Tek ships, has no such sanctioned bridge.

Commlink was the diskette-era route that did the same job for Hy-Tek alone, and the periodical record above shows the two treated as alternatives for years rather than one replacing the other.

Compared with Lenex¶

Lenex is the European equivalent and answers the same need in a different technical idiom. It is XML rather than fixed-width, is written as a .lef file and usually shipped zipped as .lxf, and is created and maintained by Christian Kaufmann, not by a federation. Version 1.0 was in use across European countries from 1999, version 2.0 arrived in 2004 alongside the launch of European Rankings, and version 3.0 followed in late 2008 while staying close to backward compatible with its predecessor. It is the recommended format for European Aquatics rankings and is described as the primary exchange format of more than twenty federations.¹¹

The two differ in date and in approach, though not in ambition. SDIF fixed its record geometry in the diskette era and has not moved since 1998. Lenex began a year after SDIF’s last revision and chose a self-describing format. It has had three version numbers, and since 2008 its documentation has been extended many times while the version number stayed at 3.0. Where SDIF has to add a record type to carry a longer identifier, an XML format adds an attribute. SDIF puts a swim on one line; Lenex spreads it across a tree joined by numeric identifiers, as the Lenex page’s worked example shows.

Reading and writing¶

Implementations exist in several languages, and what they enforce is a useful check on what the specification permits. swimlib, in TypeScript, reads and writes SD3 along with HY3 and several other formats, and reads CL2 by running its SDIF parser with the mandatory-field checks relaxed and checksum validation switched off, which is about as precise a statement of the closeness of the two formats as anyone has made.¹² A Python implementation published in 2023 worked from the same usms.org document and records that Meet Manager in practice needs only the A0, B1, C1, D0 or D1, and Z0 records, which is a narrower set than the specification allows for.¹³

Importers are unforgiving in practice. A thread on the sdif-forum group follows someone generating an entries file by hand whose file was rejected outright, and the cause turned out to be the spreadsheet writing Unicode with hidden formatting in place of plain text.¹⁴ Byte-level exactness and record order both matter, which is the practical consequence of a format that has no checksum to tell a reader where a file went wrong. Validation utilities exist to fill that gap, including SDIFCheck and the SDIF Master and SDIF_PRO extraction tools.¹⁵³

Gaps¶

SWIMS accepts the format and an XML variant beside it, but USA Swimming’s own documentation of XSDIF is no longer reachable, so what is said above rests on an LSC’s procedure document rather than on the publisher. No specification for the XML form has been found at all.

Versions 1 and 2 are known only through version 3’s account of what it changed. Whether the stroke code used for diving is a documented vendor extension or a local convention is unresolved. Whether writers other than Meet Manager count D3 records the same way in the terminator is untested, because only one file was available.

References¶

USA Swimming, Standard Data Interchange Format version 3 (28 April 1998). ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵
Meet results file for a 2026 NCAA Division III conference championship, written by Hy-Tek Meet Manager (unpublished; examined for this article). ↩ ↩² ↩³ ↩⁴ ↩⁵
Swim Data, SDIF (the identifier change behind version 3, and the SDIF Master and SDIF_PRO utilities). ↩ ↩²
Swimming World, December 1994 (United States Swimming on vendor adoption and Top 16 tabulation). ↩
Swimming World, May 1998 (times accepted in an SDIF-compatible format or in Commlink). ↩
Swimming World, September 2000 to January 2001 (Hy-Point Software advertisements for SwimMeet Manager). ↩
SwimNews, November 2001 (world ranking database launch; results wanted as SDIF or Commlink). ↩
SwimNews, May–June 2002 (meet-management advertisement listing Commlink, SDIF, WSV, Lenex and Aquabec). ↩
Snake River Swimming, Required Procedures for Electronic Athlete Registrations via Team Unify (2016; the formats SWIMS accepts). ↩
HY-TEK, Convert a Hy-Tek Export CL2 File to SDIF (Meet Manager 8 user guide). ↩
Swimrankings, Lenex (authorship, version history and adoption). ↩
dmanusrex, swimlib (TypeScript; reads and writes SD3, and reads CL2 through a relaxed SDIF parser). ↩
tdsmith, sdif (Python, 2023; the records Meet Manager requires in practice). ↩
sdif-forum (an entries file rejected over text encoding). ↩
WinSwim, SDIFCheck (validation utility). ↩

Last updated September 25, 2026.