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
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.
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
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 ¯_(ツ)_/¯
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.
@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.
Sorry, I just saw that the csv exported from Android doesn’t even have the timestamp_measurement column. What a nightmare.
David mentioned in a previous post that he’s added support for local time, after a similar complaint/comment from Samantha.
Thanks Gerald, that does indeed fix the issue for Android users who are facing the same problem as I am. The iOS app doesn’t produce a local time column unfortunately, instead the correct time and date is stored in the timestamp_measurement column which is formatted like this: 2024-03-28 08:24:25 +0000
I’m using iOS and have never experienced the problem. That said, I’m not in a country where daylight savings is used. Would be interesting to see if this only affects daylight savings users.
Could you please mail me (david@intervals.icu) one of your files and I will see if I can do something with that timestamp_measurement column without breaking things for everyone.
Thanks for sending me the file. I have updated the import to use that column if it is available and treat it as a local date. Hopefully this doesn’t break things for anyone.