Y2K16

[bustavo]

list_cgm.py started converting all dates to year 2000... unless the data from the pump is incorrect and this is a pump history bug.

I already tried resetting the time on the pump, but the data still has 2000 on the output records, the date on pump is ok.

This happened after a bg calibration last night:

{
    "name": "GlucoseSensorData", 
    "date_type": "prevTimestamp", 
    "_tell": 120, 
    "sgv": 104, 
    "date": "2016-01-01T04:11:00", 
    "packet_size": 0, 
    "op": 72
  }, 
  {
    "body": "8e", 
    "packet_size": 5, 
    "amount": 102, 
    "name": "CalBGForGH", 
    "raw": "03-79-01-10-8e", 
    "date": "2000-01-01T03:57:00", 
    "date_type": "minSpecific", 
    "_tell": 125, 
    "op": "0x0e"
  }, 
  {
    "name": "GlucoseSensorData", 
    "date_type": "prevTimestamp", 
    "_tell": 112, 
    "sgv": 108, 
    "date": "2000-01-01T04:15:00", 
    "packet_size": 0, 
    "op": 74
  }, 

In the meanwhile, I am setting the year manually to 2016.

[scottleibrand]

Yep, this is affecting everyone in #intend-to-bolus. The current workaround for oref0 users is to s/2000-/2016-/g, like:

openaps alias add fix-history '! bash -c "sed -i \"s/2000-/2016-/g\" monitor/pumphistory.json monitor/clock.json"'
openaps alias add fix-iob "report invoke monitor/pumphistory-zoned.json monitor/clock-zoned.json monitor/iob.json"
openaps alias add gather '! bash -c "rm monitor/*; ( openaps get-bg | grep reporting && echo -n Re && ( openaps monitor-pump && openaps fix-history && openaps fix-iob ) >/dev/null && echo -n fresh && ( openaps ns-meal-carbs; echo ed: ) && ls -C monitor/ ) 2>/dev/null"' || die "Can't add gather”

[ps2]

minimed_rf is parsing the dates fine here: https://github.com/ps2/minimed_rf/blob/master/lib/minimed_rf/log_entries/base.rb#L33 I know I've seen the equivalent code in decocare. Just need to find it again.

[ps2]

Changing this line: https://github.com/bewest/decoding-carelink/blob/master/decocare/records/times.py#L12 to year = 0x1f seems to fix the issue, but I'm not 100% it won't cause regressions elsewhere.

[loudnate]

Yep, today is the day of reckoning, where we find out if Minimed really planned their date decoding to work up to 2016.

2000 is the epoch, and +16 now requires 5 bits instead of four.

I'm sorry, we totally saw this coming a few months ago and forgot to act on it.

On Jan 1, 2016, at 8:56 AM, Pete Schwamb notifications@github.com wrote:

Changing this line: https://github.com/bewest/decoding-carelink/blob/master/decocare/records/times.py#L12 to year = 0x1f seems to fix the issue, but I'm not 100% it won't cause regressions elsewhere.

— Reply to this email directly or view it on GitHub.

[loudnate]

I think @ps2 is correct. I don't recall ever seeing any more than one extra year bit as metadata, but maybe it's best to be safe and use the 0x1f mask instead.

On Jan 1, 2016, at 8:48 AM, Pete Schwamb notifications@github.com wrote:

minimed_rf is parsing the dates fine here: https://github.com/ps2/minimed_rf/blob/master/lib/minimed_rf/log_entries/base.rb#L33 I know I've seen the equivalent code in decocare. Just need to find it again.

— Reply to this email directly or view it on GitHub.

[ps2]

In minimed rf, I use 7 bits (see ref above). IIRC, this was from setting the pump date as far as it would go in the future. That would get us out to year 2127.

Edit: Just checked on a 523, and the max it can be set to is 2099. That still requires 7 bits, though.

[ps2]

I just wasn't sure if that Mask was used in other contexts that it might not be appropriate to increase the width.

[scottleibrand]

Confirmed fixed when installing from dev branch.