8000 fix(cbio): name the sensor counter a counter, not a clock by shroominic · Pull Request #171 · shroominic/OpenGlucose · GitHub
[go: up one dir, main page]

Skip to content

fix(cbio): name the sensor counter a counter, not a clock - #171

Closed
shroominic wants to merge 1 commit into
feature/cbio-gs1-glucose-livefrom
fix/cbio-sensor-counter-not-epoch
Closed

shroominic wants to merge 1 commit into
feature/cbio-gs1-glucose-livefrom
fix/cbio-sensor-counter-not-epoch

Conversation

@shroominic
Copy link
Copy Markdown
Owner

Closes #146.

The defect

The archive called the 08 batch's second counter "Sensor-recorded epoch
seconds" and exposed it as oldestTime / newestTime. From #146's arithmetic:

Observation Value
stored records 5680 -> 6128 (+448)
rendered "latest" 01:36 -> 09:04 (+7 h 28 m)
448 records x 60 s 7 h 28 m

The counter advances exactly one step per stored record, so anything that turns
it into HH:mm reports the ingest position and calls it a clock. The rendered
+7h28m skew is the per-record counter, not UTC.

The fix

  • oldestTime / newestTime become oldestSensorCounter /
    newestSensorCounter. The time-shaped names were the invitation to build a
    DateTime from it.
  • CbioRawGlucoseRecord.rawTime and CbioPackedRecord.rawTime are documented
    as the epoch-less per-record counter, explicitly not Unix time, and explicitly
    not derivable into a clock without the sensor's activation time.
  • A regression test pins the relationship (span == 60 * (records - 1)) and
    fails if either removed name comes back.

Verification

  • packages/cgm_cbio: flutter test 61 passed; flutter analyze clean;
    dart format --set-exit-if-changed lib test clean.

Scope note

This lane removes the trap at the source. The downstream rendering fix - the
session no longer inventing a timestamp (recordedAt: null) and the hero
reporting the protocol position instead - lives in the live-session branch
(#142), which #146 already documents.

8000
The archive documented the field as 'Sensor-recorded epoch seconds' and exposed
it through oldestTime/newestTime. It is the batch base plus 60 per record: an
epoch-less position that advances exactly one step per stored record, so a
surface that renders it as HH:mm reports ingest position and calls it a wall
clock.

Name it for what it is. oldestSensorCounter/newestSensorCounter replace the
time-shaped getters, the field docs say it is not Unix time and cannot yield a
clock without the sensor activation time, and a regression test pins the
one-step-per-record relationship and fails if either old name comes back.

Refs #146
@shroominic
Copy link
Copy Markdown
Owner Author

Not absorbed by the GS1 consolidation (#209, feature/cbio-gs1). Left open on purpose so the naming defect is not silently dropped: the epoch-less counter naming is not in the consolidated tree - cbio_history_archive.dart still reads "Sensor-recorded epoch seconds, from the batch base plus 60 s per record", and oldestTime/newestTime are unchanged. Owner: sensor/GS1 lane.

@shroominic
Copy link
Copy Markdown
Owner Author

Carried into #209 (head be9b47a) as the commit of the same name — the rename applied to the consolidated branch, with one adaptation recorded here.

  • CbioHistoryArchive now publishes oldestSensorCounter / newestSensorCounter; the time-shaped oldestTime / newestTime are gone and the suite asserts they stay gone.
  • rawTime is documented as an epoch-less per-record counter, in both the archive record and the packed record.
  • Adaptation: this line also carries the record-index clock anchor, so the session's live-edge gate had to read the renamed getter. That gate is documented as an observation — the counter compared against the app's own clock — and the archive doc states that the only timestamp a record can carry comes from an anchor, which exists only once the sensor's own counter agreed with the clock the app wrote. Behavior is unchanged; the counter is never rendered as a clock.

#146 closes when #209 lands on main; nothing in this line merges to main yet, so it stays open for now. Carrying PR: #209.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

0