Hrv4training results off by one day

There’s something else odd. The date and timestamp aren’t different by a whole number of hours.
It’s 5:55:33 different.
And if you’re 6 hours ahead of UTC you should have run into the same problem. You would have run into it if that difference had been correct.
Perhaps the date field is just
UTC date, arbitrary 1 minute to make sure its past midnight, meaningless +0000

If your other rows in the table are the same then that’s it.

date,timestamp_measurement,HR_lying,HR_standing,AVNN_lying,AVNN_standing,SDNN_lying,SDNN_standing,rMSSD_lying,rMSSD_standing,pNN50_lying,pNN50_standing,LF_lying,LF_standing,HF_lying,HF_standing,LFHF_lying,LFHF_standing,test_duration,HRV4T_Recovery_Points,training,training_performance,training_type,training_phase,physical_condition,trainingRPE, trainingTSS, suffer_score, trainingMotivation, trainingDistance, sleep_quality,sleep_time,sleep_tobed,sleep_awake,mental_energy,muscle_soreness,fatigue,traveling,sickness,alcohol,baseline,advice,note,signal_quality, location, supplements, diet, custom_tag_1_name, custom_tag_2_name, custom_tag_3_name, custom_tag_1_value, custom_tag_2_value, custom_tag_3_value, menstrual_cycle, trainingTime, current_lifestyle, run_distance, run_time, run_pace, run_hr, run_elevation, bike_distance, bike_time, bike_speed, bike_elevation, bike_hr, bike_power, swim_distance, swim_time, swim_speed, swim_hr, vo2max, latitude, longitude, altitude, temperature, humidity, daily_message, injury

that’s the entire header… lots of stuffs
2023-10-05 00:01:00 +0000,2023-10-05 06:16:10 +0000,
2023-10-06 00:01:00 +0000,2023-10-06 05:56:33 +0000,

These are how the rows look. the 1min past midnight seems a bit ominous lol…
but I think you’re right, the +0000 is meaningless as It’s LocalTime, I’m GMT+8, not sure about UTC tho. Don’t think I’ll have any issues given that it’s in localtime.

Oh, so you’re not far from me! In fact you could be in Western Australia.
And you have rows where the date and the local date are different and yet you haven’t seen this problem?
Curiouser and curiouser!

I see what you mean about the format of the file being different!! There’s no lying and standing measurements. The app itself must be quite different I think.

This is the android header:
date local time HR AVNN SDNN rMSSD pNN50 LF HF HRV4T_Recovery_Points training training_performance training_type training_phase physical_condition trainingRPE trainingTSS trainingMotivation trainingDistance sleep_quality sleep_time sleep_awake sleep_tobed mental_energy muscle_soreness fatigue lifestyle traveling sickness alcohol note signal_quality location supplements diet custom_tag_1_name custom_tag_2_name custom_tag_3_name custom_tag_1_value custom_tag_2_value custom_tag_3_value menstrual_cycle trainingTime run_distance run_time run_pace run_hr run_elevation bike_distance bike_time bike_speed bike_elevation bike_hr bike_power swim_distance swim_time swim_speed swim_hr vo2max suffer_score latitude longitude altitude temperature humidity daily_message

I didn’t check all but they seem to be in sequence. the date is always there, but timestamp_measurement only when i actually measure and I only measure upon waking up, so theres no issue w/ crossing over to the next day.

Tho I have to admit, I don’t pay close attn to it enough to see if it’s every “off” by a day or such.

Could you please mail me (david@intervals.icu) a few lines from the file with the header line and I will see if I can use that local column. Tx.

I have added support for that local column. It will be used instead of the date column if present. Tx for sending me the data.

2 Likes

This may be a coincidence (this does happen from time to time), but this morning HRV4Training data did not upload. When I look at the Settings | DropBox | Import HRV4Training I see the following:

  • 4 minutes ago ~ Line 2: Bad local [2020-21-12]

I have the Local column, and this is with the Android HRV4Training app.

Edit: The entry for 2020-21-12 is the first row of data in this file, and the ‘date’ and ‘local’ cells are identical.

Robert

lol… this is sad and yet funny…

presume it’s the latest update?

Yes, the latest version (20th September 2023), so presumably the ‘local’ field was added then (or earlier), and the failure to import is possibly correlated with the change David applied.

Robert

david will need to see how to sort it out… Quite possibly w/ all the different permutations of output the app has, might have to jumpt thru a few hoops.

I seem to remember that when David set up the upload there was some issue with the date format. And the file name from the iOS worked differently from the Android app.

Robert

Same error for me,
HRV4T (android) > Dropbox > Intervals
~ Line 2: Bad local [2020-13-11]

I’m using iOS without any problems, so could this be an Android-only issue?
IMG_0051

@Gerald - your file doesn’t have the ‘local’ column, does it? In my Android file it comes right after the ‘date’ column.

Robert

No, it only has the date in the second column, and a timestamp in the third column. See details of the difference between the two dates.

I have ‘date’, ‘local’, ‘time’ as the first three data columns. ‘local’ is always the same as ‘date’, and ‘time’ is always my local time.

Robert

Well I know this is unhelpful but it worked perfectly for me. But I guess I’m “behind” you guys so you may have bumped into David tinkering.

Maybe it will work today/tomorrow… Whatever the heck day it is for you. Are you all south Africans by any chance?

Thank you soooo much David. It works perfectly! Thank you somuch as always for the time you spend on an these improvements.

1 Like

I’m in the UK. HRV4Training upload was fixed yesterday, and was fine for this morning’s measurement (11th October).

R

2 Likes

@david I’m now getting the issue of my HRV4Training data being flagged for the previous day using Android. It looks like Intervals is using the “Local” field instead of the Date field and for some reason my “Local” field is offset by a day. I’m US-based if that potentially has anything to do with it.