@domorium/validator 1.6.0 → 1.8.0

package/CHANGELOG.md

@@ -2,6 +2,53 @@
 
 All notable changes to `@domorium/validator` are documented here.
 
+## 1.8.0 - 2026-08-14
+
+- **A header naming a system before `GEDC` is Personal Ancestral File, and is no
+  longer judged by a specification that does not apply to it.** FamilySearch's
+  version-detection algorithm reads until whichever of `1 GEDC` and `1 SYST`
+  comes first; `1 SYST` skips the version entirely and sends the file to the PAF
+  specification. We read the `VERS` line regardless, resolved 5.5.1 and reported
+  five diagnostics from a schema the algorithm says is not the file's.
+- `VAL015` says so and nothing else is reported, the way an unsupported version
+  already behaves. `getVersionResolution()` gains a `paf` kind carrying the
+  system the header named. Writing a PAF schema is not in scope; saying plainly
+  that this dialect is not judged here is.
+- A `1 SYST` **after** `1 GEDC` changes nothing, which is what the algorithm
+  says: whichever comes first decides.
+
+## 1.7.0 - 2026-08-13
+
+- **A date payload offers completions, and they depend on where the cursor is.**
+  Typing one got no help at all, in a format where the help is most needed. The
+  start of a value offers the calendars, the modifiers and the months; after a
+  number, the months it could still take and the epoch it could already be;
+  after `BET`'s first date, `AND`; after `FROM`'s, `TO`. An exact date is offered
+  months alone, since its grammar admits no calendar and no epoch.
+- **The months offered are the ones the calendar in force actually has.**
+  a cursor after `HEBREW 1` offers `TSH` through `ELL`, one after `FRENCH_R`
+  offers `VEND` through `COMP`, and the twelve a user knows by heart are not among them. This is the
+  case the feature is for.
+- GEDCOM 7 only. 5.5.1 keeps its months in a regular expression and its
+  `calendar` section is empty, so there is nothing there to offer from.
+
+- **A date naming a day the calendar does not have is reported.** `31 FEB 1900`,
+  `31 APR 1880`, `0 JAN` and `99 JAN` were all accepted: the grammar gives a day
+  as one or two digits, and nothing looked at the month it belongs to. Each now
+  carries `VAL014` saying which day was named and how many the month has. So does
+  `29 FEB 1900` — a year divisible by 100 and not by 400 has no 29th — while
+  `29 FEB 2000` and `29 FEB 2024` stay quiet.
+- The check is separate from the grammar and reported with a code of its own,
+  because `31 FEB 1900` _is_ a date: telling its author it is not one would say
+  the wrong thing about a value they can see is a date.
+- **A Julian date is judged by the Julian rule**, which keeps every fourth year
+  leap with no exception for centuries, so `JULIAN 29 FEB 1700` is accepted where
+  the same day in the Gregorian calendar is not. `HEBREW` and `FRENCH_R` have
+  months of their own and are not judged by anyone else's calendar. Both dialects
+  are covered, including 5.5.1's `@#DJULIAN@` escape.
+- A phrase is removed before a value is read as a date, so
+  `INT 1900 (born 31 FEB by the old reckoning)` reports nothing.
+
 ## 1.6.0 - 2026-08-12
 
 - **A fragment can be checked without being told it is not a file.** Text that is

package/dist/completion/dateSlot.d.ts

@@ -0,0 +1,17 @@
+/**
+ * Which part of a date the cursor is in. A flat list would be worse than
+ * nothing here: the months worth offering depend on the calendar named a few
+ * tokens earlier, and the keywords depend on what the value opened with.
+ */
+export type DateGrammar = "value" | "period" | "exact";
+export interface DateSlot {
+    /** A calendar may be named here. */
+    calendars: boolean;
+    /** Whose months may be named here, or null where none may. */
+    months: string | null;
+    /** Whose epochs may be named here, or null where none may. */
+    epochs: string | null;
+    /** Bare words the grammar allows here. */
+    keywords: string[];
+}
+export declare function dateSlot(typed: string, grammar: DateGrammar): DateSlot;