Hrv4training results off by one day

Yep, in Brazil with -3 GMT. Sent a message to hello@hrv4training.com detailing the bug and asking for them to fix this on their next update. Would suggest to do the same so they can prioritize fixing this.

Well, without any coding knowledge I managed to prompt chatgpt to write a powershell script that fix the problem. Now I scheduled it to run in the morning and voilá!

Hope this helps


Define the file paths

$sourceFilePath = “D:\Dropbox\Aplicativos\HRV4Training\My_Measurements_Android.csv”
$outputFilePath = “D:\Dropbox\Aplicativos\HRV4Training\hrv.csv”

Read the CSV file

$data = Import-Csv -Path $sourceFilePath

Update the “local” column with values from the “date” column

foreach ($entry in $data) {
$entry.local = $entry.date
}

Create a CSV string without quotes

$csvContent = ($data | ConvertTo-Csv -NoTypeInformation) -replace ‘"’

Save the CSV content to a new file

$csvContent | Out-File -FilePath $outputFilePath -Encoding UTF8

Write-Host “Script executed successfully. Updated data saved to: $outputFilePath”


1 Like

When I upload the csv by clicking options-wellness-upload csv I get: Invalid wellness col [timestamp_measurement]

Android or iOS?
Apparently the file structure is different between the 2 OSes (and also by version)

iOS, latest version. Sorry for not finding this thread before creating a new one.

I just tried syncing and it worked.
I’m on Latest HRV4Training iOS as well (i went to App Store and check if there are any new update. There was none)

Then I opened RV4Training and did the Data Export. Then i see intervals.icu picked up the file from dropbox and there was no complains.

Invalid wellness col [timestamp_measurement]

This is Mine. Seems to be the same “timestamp_measuremnt” column. Perhaps share yours? Just the Headers would do.

My date and timestam_measurement looks like this:
2024-02-17 00:01:00 +0000,2024-02-17 08:40:51 +0000,

By the way I don’t go through dropbox but rather options-wellness-import

When u go thru wellness import and the CSV. you need to pay attention to the exact header and the contents. There is a specific format. I don’t believe timestamp_measurement is in the list. You can try download the wellness as CSV and then open it up in notepad and compare the headers.

Yes, so import through dropbox works. However, I don’t use dropbox, so I guess I’ll add a feature request to import without

Saw ur other post. Valid request. While Dropbox is Free signup (and u get like 2GB) I do agree it can be “signup fatigue” for yet another app. Yet another login/pass account.

I only have the default iCloud (and it’s not enough for even backup) so I use Dropbox.

1 Like

Once setup, there is no need to visit DropBox again, other than to clear out the files occasionally; I can do that from the phone app.

I have now setup the dropbox import. The only issue I see is that intervals.icu is supposed to automatically update new data when it detects changes to the file. However, the export in the app itself exports a new file every time. Thus the detect changes functionality will not work. Perhaps it should instead listen to new files on the HRV4TRAINING folder in Dropbox, generated by the app? I have also contacted the developer of the app to ask if it is possible to use a generic filename, but I think the smarter choice would be to listen on folder level. Thoughts David?

Yea. That’s how it currently works. New file name. But it’s also detected by intervals.icu and will get loaded.

Edit: sigh… should have given you my referral link. Then u and I could have gotten extra free storage

have you tried it out and confirmed it doesn’t work?
You need to give Intervals.icu access to the entire folder (or ALL folders IIRC. There was a thread somewhere discussing the merits/downside of giving access to ALL)

Edit: This is my folder. All works.

Am I the only one who is still experiencing this date shift issue? I am importing via dropbox and using the latest version of the HRV4training iOS app.

The first two headers of the csv are date & timestamp_measurement. In the date column, the date is always the day prior to the measurement with a time set for 23:01:00.
For todays measurement, the date is given as 2024-03-27 23:01:00 +0000 and the timestamp is 2024-03-28 08:24:25 +0000 . Intervals.icu interprets the date column instead of the timestamp_measurement column and thus my readings are always tagging behind by one day.

Has someone found the root of this issue or good solution for it?
I am considering writing a script for excel or to manipulate the csv in a text editor, but this would only be a temporary fix for something that should otherwise work, right? I am also worried that any script I write would be useless by Sunday, when we shift to summer time here in EU/Belgium.

I’m on this exact method and things are working for me. Far as I can tell anyways.

Here’s a screenshot of mine posted a while back. Mine’s at 12:01

Screenshot 2024-03-28 at 6.45.41 PM

I’ll remind myself to do a reading tomorrow morning and report back. Right now, I can’t remember if these dates are today or yday cos I don’t test everyday

Thank you, it is interesting that your date is formatted as 1 minute into the correct day while I am exactly 59 minutes before the correct date. Would you share in which time zone you are in? And can you see any change in the way this data is formatted based on whether you are in daylight savings time or not?

Oh… didn’t see this as properly as I should. You’re right, your timestamp/dates are day before at 23:01 vs mine is 12:01 into the correct date. (as evidenced by the timestamp_measurement colum)

I’m at +0800 and there’s no daylight savings here.

note that HRV4Training puts everything as +0000, so ¯_(ツ)_/¯

1 Like

If you had said you were off my time zone by one hour that would somehow explain this issue but this keeps me even more puzzled!
Thanks for checking your data for me, I’ll have a look at the date data HRV4 gives me on Sunday again, when we go into daylight savings.

1 Like

@david Would it be an option to ignore the date column completely and take the date from the timestamp_measurement column instead?

Of course that’s nonsensical if I am the only one with problems here but it seems that the date column is always strangely formatted (i.e. 1m after the start of the day, or in my case 59m before the start of the day). The timestamp_measurement column however seems to be precise and display the current date consistently correctly.