# manufacturing.lot-number
Builds a lot (batch) code from the production date, the line and a sequence
number, in one fixed format:
YYDDD-LL-SSS
- `YY` - the last two digits of the year
- `DDD` - the day of the year, 001 to 365 (366 in a leap year): the "Julian
date" printed on food, drink and pharmaceutical packs
- `LL` - the production line, 01 to 99
- `SSS` - the lot's sequence number on that line that day, 001 to 999
So lot 12 on line 3 on 1 March 2026 is `26060-03-012`, and the same lot a year
earlier, in a leap year, would be `24061-03-012` on 1 March 2024: 29 February
moves every later day of the year by one, which is the mistake a hand-built
month table makes.
**Deterministic.** The code depends only on its three arguments. The function
never reads the clock and never counts: the caller owns the sequence (from the
database row that records the lot) and passes the date the lot was made. The
same arguments always give the same code, so a code can be regenerated for a
recall.
**Fixed width.** Every code is 12 characters, so codes sort by date within a
century, then line, then sequence, and fit a fixed field on a label.
**Two-digit years repeat every century.** `26060` is 1 March 2026 and 1 March
2126. Lots are not kept that long, but the code is not a date to parse back
without context.
"Julian date" here is the day-of-year convention used on packaging, not the
astronomical Julian Day Number. Day numbers come from `dates.add-days`, so leap
years follow the full Gregorian rule (2000 was a leap year, 1900 was not).
A line outside 1-99, a sequence outside 1-999, or a date that does not exist
(2026-02-30) is an error rather than a code that would not fit the format.