Ticket Created
over 3 years ago

CIQQA-1023

Is there a bug in getStressHistory and getBodyBatteryHistory ?

I see some very strange results returned by the recently published getStressHistory function (similar with getBodyBatteryHistory). It is wrong even in simulator, but on a real device it is even worse.

sensorIter = SensorHistory.getStressHistory({ :period => 1, :order => SensorHistory.ORDER_NEWEST_FIRST});

mTime = $.sensorIter.getNewestSampleTime();
// Simulator:
// Returns current date - correct
// Real device Vivoactive 4:
// 2 possibilities: 
// 1. If iterator is empty, returns 30/12/1989 ?!
// 2. If iterator has data, returns correct date

mData = $.sensorIter.getMin();
// Simulator:
// Returns correct value (35 in my case)
// Real device Vivoactive 4:
// 2 possibilities: 
// 1. If iterator is empty, returns 127 (that is stress level 127% ?!)
// 2. If iterator has data, returns correct value

mSensorSample = sensorIter.next();
// Real device Vivoactive 4:
// Often returns NULL

if (mSensorSample != null) {
    mTime = mSensorSample.when;
    // On both, simulator and real device, returns next day but year 2002 !
    // For example, today it shows 27/3/2002 (it should be 26/3/2022)
}

Main issues:

  • On real device often returns empty iterator
  • When use next(), always returns wrong date (year 2002)
  • getMin() returs 127 (%) instead of null from empty iterator

There is a lot more weird behavior, but this is the main issue. I tried a few simulators (different watch models) - it is always the same. I have only one compatible physical watch - Vivoactive 4, and that is the result from it. Let me know if you want a sample code to try yourself.

, would you please take a look?

Thanks!

Parents
  • I want to correct some misinformation in this thread, since it has been repeated in more recent threads, and ppl have taken it at face value.

    1) The Garmin epoch starts on Dec 31, 1989 00:00 UTC, not Jan 1, 1990.

    2) The fix isn't to add "20 years worth of seconds", it's to add exactly 631065600 seconds, which is the *exact* different between the Garmin epoch and the unix epoch (Jan 1, 1970). You can see this by plugging that value into any online unix time calculator (such as https://www.unixtimestamp.com/) and verifying that you get Dec 31, 1989.

    Even the comment linked by jim_m_58 specifies adding 20 * Gregorian.SECONDS_PER_YEAR - Gregorian.SECONDS_PER_DAY, which happens to be exactly equal to 631065600.

    Source: [https://developer.garmin.com/fit/cookbook/datetime/]

Comment
  • I want to correct some misinformation in this thread, since it has been repeated in more recent threads, and ppl have taken it at face value.

    1) The Garmin epoch starts on Dec 31, 1989 00:00 UTC, not Jan 1, 1990.

    2) The fix isn't to add "20 years worth of seconds", it's to add exactly 631065600 seconds, which is the *exact* different between the Garmin epoch and the unix epoch (Jan 1, 1970). You can see this by plugging that value into any online unix time calculator (such as https://www.unixtimestamp.com/) and verifying that you get Dec 31, 1989.

    Even the comment linked by jim_m_58 specifies adding 20 * Gregorian.SECONDS_PER_YEAR - Gregorian.SECONDS_PER_DAY, which happens to be exactly equal to 631065600.

    Source: [https://developer.garmin.com/fit/cookbook/datetime/]

Children
No Data