@persei/perseed-api 5.0.20 → 5.0.22

package/dist/ecosystem-container-widget.cjs.map

@@ -1 +1 @@
-{"version":3,"file":"ecosystem-container-widget.cjs","sources":["../../src/v2/modules/ecosystem/container-widget/container-widget.helper.ts"],"sourcesContent":["import { getPeriodStart, subtractPeriods, toCalendar } from '../../global/dates/dates.helper'\nimport { getWeekStart } from '../../global/locale/locale.helper'\nimport { type RelativePeriodConfig, type TrendWindow, type TrendWindowConfig } from './container-widget.schema'\n\n/**\n * Trend-widget time windows: the `value`/`from`/`to` → concrete-window resolution shared by the trend\n * widget (front, viewer-local) and the health-data time-range filter (backend, UTC). Built on the\n * generic calendar primitives of `global/dates` (which take the week start as a plain number) and the\n * locale week-start resolver of `global/locale`, so the trend-specific rules live here in one place.\n *\n * The `utc` flag is forwarded to the primitives: `false` (default) uses the ambient local calendar\n * (the front, viewer's timezone); `true` uses UTC (the backend). Both callers produce the exact same\n * window for the same inputs and timezone.\n */\n\n/**\n * Resolves a `from`/`to` range into a concrete, calendar-aligned window. `fromValue` and `toValue`\n * are inclusive bucket offsets (\"N units ago\"), so the window covers the **complete** buckets from\n * `toValue`-ago up to `fromValue`-ago (both ends inclusive) and spans `fromValue − toValue + 1`\n * buckets:\n *\n *   - `start` (inclusive) = `getPeriodStart(now − fromValue·unit)` — start of the oldest bucket.\n *   - `end`   (exclusive ms bound) = `getPeriodStart(now − (toValue − 1)·unit)` — the start of the\n *     bucket just after the newest included one, i.e. the end of the `toValue` bucket. When\n *     `toValue = 0` this is the start of the next bucket, so the current (in-progress) bucket is\n *     included in full — the window has no `now` cap, both extremes are complete buckets.\n *\n * Example (unit = week, weekStart = 1 Monday, now = Tue 2026-07-07):\n *   from 2, to 0 → [Mon 22 Jun, Mon 13 Jul)     (3 weeks, the current one included in full)\n *   from 3, to 1 → [Mon 15 Jun, Mon 06 Jul)     (3 complete weeks, the current one excluded)\n */\nexport function resolveTrendWindow(\n  nowMs: number,\n  config: TrendWindowConfig,\n  weekStart: number = getWeekStart(),\n  utc = false,\n): TrendWindow {\n  const { fromValue, unit } = config\n  const toValue = config.toValue ?? 0\n  return {\n    start: getPeriodStart(subtractPeriods(nowMs, fromValue, unit, utc), unit, weekStart, utc),\n    end: getPeriodStart(subtractPeriods(nowMs, toValue - 1, unit, utc), unit, weekStart, utc),\n  }\n}\n\n/**\n * Resolves a count-based relative period into a concrete window — the single source of truth for the\n * `value` → from/to mapping shared by every consumer (backend health-data filter, front trend widget),\n * so the \"current period counts as one of the N\" rule is defined exactly once:\n *   - including it → `from = value - 1`, `to = 0` (buckets `value-1`…0 ago, ending now);\n *   - excluding it → `from = value`, `to = 1` (`value` complete buckets before the current one).\n */\nexport function resolveRelativePeriod(\n  nowMs: number,\n  { value, unit, excludeCurrentPeriod = false }: RelativePeriodConfig,\n  weekStart: number = getWeekStart(),\n  utc = false,\n): TrendWindow {\n  return resolveTrendWindow(\n    nowMs,\n    { fromValue: excludeCurrentPeriod ? value : value - 1, toValue: excludeCurrentPeriod ? 1 : 0, unit },\n    weekStart,\n    utc,\n  )\n}\n\n/**\n * Resolves a count-based relative period into a formatted date range for the backend health-data\n * query, keeping the whole calculation (from/to mapping + the day-level rule + formatting) in one\n * shared place:\n *   - `daily`: date-only `YYYY-MM-DD`; when excluding the current period the inclusive end becomes the\n *     last completed calendar day (the day before the current period's start).\n *   - `discrete`: ISO-8601.\n *\n * Unlike `resolveTrendWindow` (which now covers the current bucket in full for the front display), the\n * query end is **capped at `now`**: a data query must never reach past the present into the rest of an\n * in-progress bucket, so `to = 0` yields \"up to now\", not \"up to the end of the current bucket\".\n */\nexport function resolveRelativeDateRange(\n  nowMs: number,\n  config: RelativePeriodConfig,\n  format: 'daily' | 'discrete',\n  weekStart: number = getWeekStart(),\n  utc = false,\n): { start_date: string; end_date: string } {\n  const { start, end } = resolveRelativePeriod(nowMs, config, weekStart, utc)\n  const cappedEnd = Math.min(end, nowMs)\n  const startDate = toCalendar(start, utc)\n  if (format === 'discrete') {\n    return { start_date: startDate.toISOString(), end_date: toCalendar(cappedEnd, utc).toISOString() }\n  }\n  const endDate = config.excludeCurrentPeriod ? toCalendar(end, utc).subtract(1, 'day') : toCalendar(cappedEnd, utc)\n  return { start_date: startDate.format('YYYY-MM-DD'), end_date: endDate.format('YYYY-MM-DD') }\n}\n"],"names":["getWeekStart","getPeriodStart","subtractPeriods","toCalendar"],"mappings":";;;;AA+BO,SAAS,mBACd,OACA,QACA,YAAoBA,aAAAA,aAAA,GACpB,MAAM,OACO;AACb,QAAM,EAAE,WAAW,KAAA,IAAS;AAC5B,QAAM,UAAU,OAAO,WAAW;AAClC,SAAO;AAAA,IACL,OAAOC,YAAAA,eAAeC,4BAAgB,OAAO,WAAW,MAAM,GAAG,GAAG,MAAM,WAAW,GAAG;AAAA,IACxF,KAAKD,YAAAA,eAAeC,4BAAgB,OAAO,UAAU,GAAG,MAAM,GAAG,GAAG,MAAM,WAAW,GAAG;AAAA,EAAA;AAE5F;AASO,SAAS,sBACd,OACA,EAAE,OAAO,MAAM,uBAAuB,MAAA,GACtC,YAAoBF,aAAAA,gBACpB,MAAM,OACO;AACb,SAAO;AAAA,IACL;AAAA,IACA,EAAE,WAAW,uBAAuB,QAAQ,QAAQ,GAAG,SAAS,uBAAuB,IAAI,GAAG,KAAA;AAAA,IAC9F;AAAA,IACA;AAAA,EAAA;AAEJ;AAcO,SAAS,yBACd,OACA,QACA,QACA,YAAoBA,0BAAA,GACpB,MAAM,OACoC;AAC1C,QAAM,EAAE,OAAO,QAAQ,sBAAsB,OAAO,QAAQ,WAAW,GAAG;AAC1E,QAAM,YAAY,KAAK,IAAI,KAAK,KAAK;AACrC,QAAM,YAAYG,YAAAA,WAAW,OAAO,GAAG;AACvC,MAAI,WAAW,YAAY;AACzB,WAAO,EAAE,YAAY,UAAU,eAAe,UAAUA,YAAAA,WAAW,WAAW,GAAG,EAAE,cAAY;AAAA,EACjG;AACA,QAAM,UAAU,OAAO,uBAAuBA,YAAAA,WAAW,KAAK,GAAG,EAAE,SAAS,GAAG,KAAK,IAAIA,YAAAA,WAAW,WAAW,GAAG;AACjH,SAAO,EAAE,YAAY,UAAU,OAAO,YAAY,GAAG,UAAU,QAAQ,OAAO,YAAY,EAAA;AAC5F;;;;"}
+{"version":3,"file":"ecosystem-container-widget.cjs","sources":["../../src/v2/modules/ecosystem/container-widget/container-widget.helper.ts"],"sourcesContent":["import { getPeriodStart, subtractPeriods, toCalendar } from '../../global/dates/dates.helper'\nimport { getWeekStart } from '../../global/locale/locale.helper'\nimport { type RelativePeriodConfig, type TrendWindow, type TrendWindowConfig } from './container-widget.schema'\n\n/**\n * Trend-widget time windows: the `value`/`from`/`to` → concrete-window resolution shared by the trend\n * widget (front, viewer-local) and the health-data time-range filter (backend, UTC). Built on the\n * generic calendar primitives of `global/dates` (which take the week start as a plain number) and the\n * locale week-start resolver of `global/locale`, so the trend-specific rules live here in one place.\n *\n * The `utc` flag is forwarded to the primitives: `false` (default) uses the ambient local calendar\n * (the front, viewer's timezone); `true` uses UTC (the backend). Both callers produce the exact same\n * window for the same inputs and timezone.\n */\n\n/**\n * Resolves a `from`/`to` range into a concrete, calendar-aligned window. `fromValue` and `toValue`\n * are inclusive bucket offsets (\"N units ago\"), so the window covers the **complete** buckets from\n * `toValue`-ago up to `fromValue`-ago (both ends inclusive) and spans `fromValue − toValue + 1`\n * buckets:\n *\n *   - `start` (inclusive) = `getPeriodStart(now − fromValue·unit)` — start of the oldest bucket.\n *   - `end`   (exclusive ms bound) = `getPeriodStart(now − (toValue − 1)·unit)` — the start of the\n *     bucket just after the newest included one, i.e. the end of the `toValue` bucket. When\n *     `toValue = 0` this is the start of the next bucket, so the current (in-progress) bucket is\n *     included in full — the window has no `now` cap, both extremes are complete buckets.\n *\n * Example (unit = week, weekStart = 1 Monday, now = Tue 2026-07-07):\n *   from 2, to 0 → [Mon 22 Jun, Mon 13 Jul)     (3 weeks, the current one included in full)\n *   from 3, to 1 → [Mon 15 Jun, Mon 06 Jul)     (3 complete weeks, the current one excluded)\n */\nexport function resolveTrendWindow(\n  nowMs: number,\n  config: TrendWindowConfig,\n  weekStart: number = getWeekStart(),\n  utc = false,\n): TrendWindow {\n  const { fromValue, unit } = config\n  const toValue = config.toValue ?? 0\n  return {\n    start: getPeriodStart(subtractPeriods(nowMs, fromValue, unit, utc), unit, weekStart, utc),\n    end: getPeriodStart(subtractPeriods(nowMs, toValue - 1, unit, utc), unit, weekStart, utc),\n  }\n}\n\n/**\n * Resolves a count-based relative period into a concrete window — the single source of truth for the\n * `value` → from/to mapping shared by every consumer (backend health-data filter, front trend widget),\n * so the \"current period counts as one of the N\" rule is defined exactly once:\n *   - including it → `from = value - 1`, `to = 0` (buckets `value-1`…0 ago, ending now);\n *   - excluding it → `from = value`, `to = 1` (`value` complete buckets before the current one).\n */\nexport function resolveRelativePeriod(\n  nowMs: number,\n  { value, unit, excludeCurrentPeriod = false }: RelativePeriodConfig,\n  weekStart: number = getWeekStart(),\n  utc = false,\n): TrendWindow {\n  return resolveTrendWindow(\n    nowMs,\n    { fromValue: excludeCurrentPeriod ? value : value - 1, toValue: excludeCurrentPeriod ? 1 : 0, unit },\n    weekStart,\n    utc,\n  )\n}\n\n/**\n * Resolves a count-based relative period into a formatted date range for the backend health-data\n * query, keeping the whole calculation (from/to mapping + the day-level rule + formatting) in one\n * shared place:\n *   - `daily`: date-only `YYYY-MM-DD`; when excluding the current period the inclusive end becomes the\n *     last completed calendar day (the day before the current period's start).\n *   - `discrete`: ISO-8601.\n *\n * Unlike `resolveTrendWindow` (which now covers the current bucket in full for the front display), the\n * query end is **capped at `now`**: a data query must never reach past the present into the rest of an\n * in-progress bucket, so `to = 0` yields \"up to now\", not \"up to the end of the current bucket\".\n */\nexport function resolveRelativeDateRange(\n  nowMs: number,\n  config: RelativePeriodConfig,\n  format: 'daily' | 'discrete',\n  weekStart: number = getWeekStart(),\n  utc = false,\n): { start_date: string; end_date: string } {\n  const { start, end } = resolveRelativePeriod(nowMs, config, weekStart, utc)\n  const cappedEnd = Math.min(end, nowMs)\n  const startDate = toCalendar(start, utc)\n  if (format === 'discrete') {\n    return { start_date: startDate.toISOString(), end_date: toCalendar(cappedEnd, utc).toISOString() }\n  }\n  const endDate = config.excludeCurrentPeriod ? toCalendar(end, utc).subtract(1, 'day') : toCalendar(cappedEnd, utc)\n  return { start_date: startDate.format('YYYY-MM-DD'), end_date: endDate.format('YYYY-MM-DD') }\n}\n"],"names":["getWeekStart","getPeriodStart","subtractPeriods","toCalendar"],"mappings":";;;;AA+BO,SAAS,mBACd,OACA,QACA,YAAoBA,aAAAA,aAAA,GACpB,MAAM,OACO;AACb,QAAM,EAAE,WAAW,KAAA,IAAS;AAC5B,QAAM,UAAU,OAAO,WAAW;AAClC,SAAO;AAAA,IACL,OAAOC,aAAAA,eAAeC,6BAAgB,OAAO,WAAW,MAAM,GAAG,GAAG,MAAM,WAAW,GAAG;AAAA,IACxF,KAAKD,aAAAA,eAAeC,6BAAgB,OAAO,UAAU,GAAG,MAAM,GAAG,GAAG,MAAM,WAAW,GAAG;AAAA,EAAA;AAE5F;AASO,SAAS,sBACd,OACA,EAAE,OAAO,MAAM,uBAAuB,MAAA,GACtC,YAAoBF,aAAAA,gBACpB,MAAM,OACO;AACb,SAAO;AAAA,IACL;AAAA,IACA,EAAE,WAAW,uBAAuB,QAAQ,QAAQ,GAAG,SAAS,uBAAuB,IAAI,GAAG,KAAA;AAAA,IAC9F;AAAA,IACA;AAAA,EAAA;AAEJ;AAcO,SAAS,yBACd,OACA,QACA,QACA,YAAoBA,0BAAA,GACpB,MAAM,OACoC;AAC1C,QAAM,EAAE,OAAO,QAAQ,sBAAsB,OAAO,QAAQ,WAAW,GAAG;AAC1E,QAAM,YAAY,KAAK,IAAI,KAAK,KAAK;AACrC,QAAM,YAAYG,aAAAA,WAAW,OAAO,GAAG;AACvC,MAAI,WAAW,YAAY;AACzB,WAAO,EAAE,YAAY,UAAU,eAAe,UAAUA,aAAAA,WAAW,WAAW,GAAG,EAAE,cAAY;AAAA,EACjG;AACA,QAAM,UAAU,OAAO,uBAAuBA,aAAAA,WAAW,KAAK,GAAG,EAAE,SAAS,GAAG,KAAK,IAAIA,aAAAA,WAAW,WAAW,GAAG;AACjH,SAAO,EAAE,YAAY,UAAU,OAAO,YAAY,GAAG,UAAU,QAAQ,OAAO,YAAY,EAAA;AAC5F;;;;"}

package/dist/ecosystem-container-widget.mjs

@@ -1,4 +1,4 @@
-import { t as toCalendar, g as getPeriodStart, s as subtractPeriods } from "./lib-XRCJ_UAQ.js";
+import { t as toCalendar, g as getPeriodStart, s as subtractPeriods } from "./dates.helper-XRCJ_UAQ.js";
 import { getWeekStart } from "./global-locale.mjs";
 function resolveTrendWindow(nowMs, config, weekStart = getWeekStart(), utc = false) {
   const { fromValue, unit } = config;

package/dist/global-dates.cjs

@@ -1,6 +1,12 @@
 "use strict";
 Object.defineProperty(exports, Symbol.toStringTag, { value: "Module" });
-const globalDates = require("./lib-CDM5aEJG.cjs");
-exports.getPeriodStart = globalDates.getPeriodStart;
-exports.subtractPeriods = globalDates.subtractPeriods;
+const dates_helper = require("./dates.helper-CDM5aEJG.cjs");
+const API_DATETIME_ACCEPTED_NOTE = "Only this spelling is accepted: `T` as the separator (a space is a 400) and an offset with minutes, either `Z` or `±HH:MM` (`+01` and `+0100` are a 400). A lowercase `t`/`z` and a fractional second are fine";
+const API_DATETIME_EXAMPLE = "2026-01-15T10:30:00Z";
+const EMITTED_DATETIME_NOTE = "Emitted as ISO-8601 in UTC";
+exports.getPeriodStart = dates_helper.getPeriodStart;
+exports.subtractPeriods = dates_helper.subtractPeriods;
+exports.API_DATETIME_ACCEPTED_NOTE = API_DATETIME_ACCEPTED_NOTE;
+exports.API_DATETIME_EXAMPLE = API_DATETIME_EXAMPLE;
+exports.EMITTED_DATETIME_NOTE = EMITTED_DATETIME_NOTE;
 //# sourceMappingURL=global-dates.cjs.map

package/dist/global-dates.cjs.map

@@ -1 +1 @@
-{"version":3,"file":"global-dates.cjs","sources":[],"sourcesContent":[],"names":[],"mappings":";;;;;"}
+{"version":3,"file":"global-dates.cjs","sources":["../../src/v2/modules/global/dates/dates.schema.ts"],"sourcesContent":["/**\n * Generic calendar unit shared by the date primitives. Pure type — the calendar arithmetic that\n * consumes it lives in `dates.helper.ts`. Domain modules that need a narrower alias (e.g. the trend\n * widget's `TrendWindowUnit`) build it on top of this one, so the set of units is defined once here.\n */\nexport type PeriodUnit = 'hour' | 'day' | 'week' | 'month'\n\n/**\n * Datetimes a request carries are declared with `format: 'date-time'` (RFC 3339): a date and a time\n * separated by `T`, an optional fraction, and a mandatory offset (`Z` or `±HH:MM`). The offset names\n * the instant; the service converts it to UTC for the column.\n *\n * The format is TypeBox's, not `ajv-formats`': routes compile through `TypeBoxValidatorCompiler`\n * (`app.ts`), and `ajv-formats` only validates the v1/Objection layer. Which one runs matters,\n * because TypeBox's is the stricter of the two and the difference is visible from outside:\n *\n * - It splits the value on `/T/i` alone, so `T`/`t` is the only separator — a space is a 400.\n * - Its offset is `(?:Z|([+-])(\\d\\d):(\\d\\d))?`, so the minutes are not optional: `+01` is a 400,\n *   and so is `+0100` without the colon. That is what keeps `dayjs.utc()` from ever seeing an\n *   hour-only offset, which it cannot read — it would fall back to parsing the value as a bare wall\n *   clock and drop the offset, storing an instant an hour off with no error.\n * - It bounds the offset to `±23:59` (`tzH > 23 || tzM > 59`), so `+99:99` is a 400, and it checks\n *   the calendar (`IsDate`, leap years included), so `2026-02-31T00:00:00Z` is a 400 before any\n *   handler runs. The bound is RFC 3339's and not the tz database's, so it also takes offsets no\n *   zone uses (`-14:00`, `+23:59`) — each still names one unambiguous instant, so what gets stored\n *   is right.\n *\n * A `pattern` alongside the format would be dead weight: everything one could reasonably spell in it\n * is already a subset of what the format checks, and a stricter one drifts silently the day either\n * side changes. This was tried and removed (persei/tasks#294).\n *\n * This is that contract in one sentence, for the description of a request field: what the format\n * takes and, just as important, the two near-miss spellings a client is likely to try.\n */\nexport const API_DATETIME_ACCEPTED_NOTE =\n  'Only this spelling is accepted: `T` as the separator (a space is a 400) and an offset with minutes, either `Z` or `±HH:MM` (`+01` and `+0100` are a 400). A lowercase `t`/`z` and a fractional second are fine'\n\n/** An RFC 3339 datetime, for schema examples and API documentation. */\nexport const API_DATETIME_EXAMPLE = '2026-01-15T10:30:00Z'\n\n/**\n * What a datetime *coming out* of the API looks like, for the description of a response field.\n *\n * The outbound shape is narrower than the inbound one and no pattern states it: datetimes leave the\n * column as `Date` and are serialised by `fast-json-stringify` with `.toISOString()`, so the schema\n * never validates what is emitted. Saying it in the description is what puts it in the published\n * spec, which is where a client reads the contract from.\n */\nexport const EMITTED_DATETIME_NOTE = 'Emitted as ISO-8601 in UTC'\n"],"names":[],"mappings":";;;AAkCO,MAAM,6BACX;AAGK,MAAM,uBAAuB;AAU7B,MAAM,wBAAwB;;;;;;"}

package/dist/global-dates.mjs

@@ -1,5 +1,11 @@
-import { g, s } from "./lib-XRCJ_UAQ.js";
+import { g, s } from "./dates.helper-XRCJ_UAQ.js";
+const API_DATETIME_ACCEPTED_NOTE = "Only this spelling is accepted: `T` as the separator (a space is a 400) and an offset with minutes, either `Z` or `±HH:MM` (`+01` and `+0100` are a 400). A lowercase `t`/`z` and a fractional second are fine";
+const API_DATETIME_EXAMPLE = "2026-01-15T10:30:00Z";
+const EMITTED_DATETIME_NOTE = "Emitted as ISO-8601 in UTC";
 export {
+  API_DATETIME_ACCEPTED_NOTE,
+  API_DATETIME_EXAMPLE,
+  EMITTED_DATETIME_NOTE,
   g as getPeriodStart,
   s as subtractPeriods
 };

package/dist/global-dates.mjs.map

@@ -1 +1 @@
-{"version":3,"file":"global-dates.mjs","sources":[],"sourcesContent":[],"names":[],"mappings":";"}
+{"version":3,"file":"global-dates.mjs","sources":["../../src/v2/modules/global/dates/dates.schema.ts"],"sourcesContent":["/**\n * Generic calendar unit shared by the date primitives. Pure type — the calendar arithmetic that\n * consumes it lives in `dates.helper.ts`. Domain modules that need a narrower alias (e.g. the trend\n * widget's `TrendWindowUnit`) build it on top of this one, so the set of units is defined once here.\n */\nexport type PeriodUnit = 'hour' | 'day' | 'week' | 'month'\n\n/**\n * Datetimes a request carries are declared with `format: 'date-time'` (RFC 3339): a date and a time\n * separated by `T`, an optional fraction, and a mandatory offset (`Z` or `±HH:MM`). The offset names\n * the instant; the service converts it to UTC for the column.\n *\n * The format is TypeBox's, not `ajv-formats`': routes compile through `TypeBoxValidatorCompiler`\n * (`app.ts`), and `ajv-formats` only validates the v1/Objection layer. Which one runs matters,\n * because TypeBox's is the stricter of the two and the difference is visible from outside:\n *\n * - It splits the value on `/T/i` alone, so `T`/`t` is the only separator — a space is a 400.\n * - Its offset is `(?:Z|([+-])(\\d\\d):(\\d\\d))?`, so the minutes are not optional: `+01` is a 400,\n *   and so is `+0100` without the colon. That is what keeps `dayjs.utc()` from ever seeing an\n *   hour-only offset, which it cannot read — it would fall back to parsing the value as a bare wall\n *   clock and drop the offset, storing an instant an hour off with no error.\n * - It bounds the offset to `±23:59` (`tzH > 23 || tzM > 59`), so `+99:99` is a 400, and it checks\n *   the calendar (`IsDate`, leap years included), so `2026-02-31T00:00:00Z` is a 400 before any\n *   handler runs. The bound is RFC 3339's and not the tz database's, so it also takes offsets no\n *   zone uses (`-14:00`, `+23:59`) — each still names one unambiguous instant, so what gets stored\n *   is right.\n *\n * A `pattern` alongside the format would be dead weight: everything one could reasonably spell in it\n * is already a subset of what the format checks, and a stricter one drifts silently the day either\n * side changes. This was tried and removed (persei/tasks#294).\n *\n * This is that contract in one sentence, for the description of a request field: what the format\n * takes and, just as important, the two near-miss spellings a client is likely to try.\n */\nexport const API_DATETIME_ACCEPTED_NOTE =\n  'Only this spelling is accepted: `T` as the separator (a space is a 400) and an offset with minutes, either `Z` or `±HH:MM` (`+01` and `+0100` are a 400). A lowercase `t`/`z` and a fractional second are fine'\n\n/** An RFC 3339 datetime, for schema examples and API documentation. */\nexport const API_DATETIME_EXAMPLE = '2026-01-15T10:30:00Z'\n\n/**\n * What a datetime *coming out* of the API looks like, for the description of a response field.\n *\n * The outbound shape is narrower than the inbound one and no pattern states it: datetimes leave the\n * column as `Date` and are serialised by `fast-json-stringify` with `.toISOString()`, so the schema\n * never validates what is emitted. Saying it in the description is what puts it in the published\n * spec, which is where a client reads the contract from.\n */\nexport const EMITTED_DATETIME_NOTE = 'Emitted as ISO-8601 in UTC'\n"],"names":[],"mappings":";AAkCO,MAAM,6BACX;AAGK,MAAM,uBAAuB;AAU7B,MAAM,wBAAwB;"}