edfcore 0.4.453 → 0.4.454

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -109,5 +109,5 @@ export declare const SIGNAL_FIELD_BLOCK_OFFSETS: {
109
109
  readonly reserved: 224;
110
110
  };
111
111
  /** Published package version. Kept in sync with package.json by a test. */
112
- export declare const VERSION = "0.4.453";
112
+ export declare const VERSION = "0.4.454";
113
113
  //# sourceMappingURL=constants.d.ts.map
package/dist/constants.js CHANGED
@@ -79,5 +79,5 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
79
79
  reserved: 224,
80
80
  };
81
81
  /** Published package version. Kept in sync with package.json by a test. */
82
- export const VERSION = '0.4.453';
82
+ export const VERSION = '0.4.454';
83
83
  //# sourceMappingURL=constants.js.map
package/docs/CHANGELOG.md CHANGED
@@ -6,6 +6,25 @@ alone does not tell you whether you were affected.
6
6
  edfcore is pre-1.0. Patch releases have carried behaviour changes where the old behaviour was a
7
7
  defect; those are called out below.
8
8
 
9
+ ## 0.4.454
10
+
11
+ - **Added** a test for `validateHeader`'s own `DATE_FIELDS_DISAGREE` check on the ordinary case:
12
+ a `dd.mm.yy` field that resolves to 2051 beside a recording identification `Startdate` that
13
+ spells 1951 out.
14
+ - `checkDates` reports that code from two arms, and only the EDF+ `yy` escape arm had ever been
15
+ run through `validateHeader`. The ordinary arm — the case the code is named for and the one
16
+ every doc page uses as its example — was covered five times over in `resolveStartTime`, which
17
+ is a different function in a different file that happens to emit the same code on the read
18
+ path. Deleting the comparison in `validate.ts` left the suite green.
19
+ - That matters because the two are deliberately independent. `validateHeader` is documented as
20
+ standing on its own so a caller can sweep a header it did not open, and 0.3.81 fixed this exact
21
+ shape of bug in the other direction: the escape arm was missing here, so the parser and the
22
+ conformance sweep disagreed about whether one file had a defect.
23
+ - The assertions are on `specReference`, not on the code. Both functions cite EDF+ additional
24
+ specification 4; only this one cites it as "(local recording identification)" and prints the
25
+ header's date as a resolved day rather than as raw bytes. A test that asserted the code alone
26
+ would have passed on the parser's diagnostic and proved nothing about the function it names.
27
+
9
28
  ## 0.4.453
10
29
 
11
30
  - **Added** tests for the date comparison behind `DATE_IMPLAUSIBLE`, at every level rather than
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "edfcore",
3
- "version": "0.4.453",
3
+ "version": "0.4.454",
4
4
  "description": "Modern, typed, zero-dependency reader for EDF, EDF+, BDF and BDF+ biosignal files. Works in browsers and Node with true random access.",
5
5
  "keywords": [
6
6
  "edf",
package/src/constants.ts CHANGED
@@ -93,4 +93,4 @@ export const SIGNAL_FIELD_BLOCK_OFFSETS = {
93
93
  } as const;
94
94
 
95
95
  /** Published package version. Kept in sync with package.json by a test. */
96
- export const VERSION = '0.4.453';
96
+ export const VERSION = '0.4.454';