edf2csv 0.5.105 → 0.5.107

package/CHANGELOG.md

@@ -3,6 +3,48 @@
 Notable changes to edf2csv. Versions follow [semantic versioning](https://semver.org); while the
 major version is 0, a minor bump may contain breaking changes.
 
+## 0.5.107
+
+### Fixed: recipes.md said the signal CSVs are already sorted, and one kind of file is not
+
+The `merge_asof` recipe for aligning two rate files closes with "Both frames must be sorted on
+the join key, which they already are." True of an ordinary recording. An EDF+D file whose data
+records are stored out of chronological order writes its rows in file order, so `time_s` comes
+out `0, 0.5, 10, 10.5, 5, 5.5` — and pandas raises `ValueError: left keys must be sorted` on it.
+
+output-files has always said this can happen, in the `time_s` section. The recipe that depends
+on it did not, and a recipe is where the claim actually gets used.
+
+Qualified, with the warning the conversion prints and the one-line fix (`sort_values` before the
+join), linked to the section that sets out when it happens.
+
+### Fixed: "1 data record start earlier than the record before it"
+
+The two warnings that report records out of order or overlapping counted with hard-coded verbs
+and pronouns. They read "starts ... before it" at one and "start ... before them" above it.
+
+## 0.5.106
+
+### Fixed: two warnings printed together, and the second denied the first
+
+```
+warning: This is a discontinuous (EDF+D) recording: its data records are not contiguous in time.
+         Each row carries its true recording time, so gaps stay visible instead of being closed.
+warning: This file is marked discontinuous but has no annotation channel, so where its records
+         sit in time is not recorded anywhere.
+         Times are written as if the records were contiguous. Any gaps are lost.
+```
+
+The column runs contiguously from zero. No row carries a true recording time, because none is
+recorded — which the second warning says plainly, four lines under the first one promising the
+opposite.
+
+The header parser raises the first, and it cannot know: whether the record starts can be derived
+is settled after the annotation channel has been read. So the promise is withdrawn where the
+answer is, the way `withoutFileRateWarning` already drops a header diagnostic the plan has
+superseded. A file that can keep it keeps it — `discontinuous.edf` still says gaps stay visible,
+and its rows still carry the nine-second gap.
+
 ## 0.5.105
 
 ### Fixed: a BDF+ recording was told it is "marked continuous (EDF+C)"

package/dist/cli.js

@@ -23,7 +23,7 @@ import { ChannelSelectionError } from './convert/channels.js';
 // Shared with the library so a bad option is the same error whichever way it arrived.
 import { OptionError } from './convert/options.js';
 import { TimeRangeError, parseTimeSpec } from './convert/time-range.js';
-import { deriveRecordStarts } from './convert/timing.js';
+import { deriveRecordStarts, withTimingPromiseKept } from './convert/timing.js';
 import { formatDiagnostics, formatInfo, infoJson, formatSummary, printable, printableLines, summaryJson } from './cli/report.js';
 import { counted, listed } from './format/list.js';
 import { VERSION } from './version.js';
@@ -750,7 +750,7 @@ async function showInfo(input, shared, asJson, jsonIndent, batch = false, toStdo
         audit?.verify();
         // Under --json the warnings travel inside the document, exactly as they do for a
         // conversion, so stderr stays empty and the whole result is one parseable thing.
-        const diagnostics = [...withoutFileRateWarning(file.diagnostics), ...plan.diagnostics];
+        const diagnostics = [...withTimingPromiseKept(withoutFileRateWarning(file.diagnostics), timing.starts !== null), ...plan.diagnostics];
         if (!asJson && diagnostics.length > 0) {
             /*
               Named when there is more than one recording to confuse it with.