Does Garmin Care?

7185080 said:

Instead what I observe is that these suggestions and bugs, are instead fixed with the next hardware release, to make you go buy the new thing, yikes.

If it makes you feel better, some of those feature requests and bugs are never resolved

Better yet, Garmin has a solid record of breaking things that worked perfectly.

It looks like they  broke CSV export in October. Before you could export a pool swim and it would have lap times, now it only exports the interval headers (manual button presses on the watch).

It doesn't seem like they added anything, just took a working function and made it worse.

Garmin software bad you say?

That does sound like an issue with Excel being crappy rather than the CSV though. I didn't have any problem parsing the times with R.

ashtermet said:

That does sound like an issue with Excel being crappy rather than the CSV though.

Exact same issue with Google Sheets and LibreOffice. I don't mention Numbers for this specific issue because Numbers doesn't let you do the same kind of math (summing/averaging) with what appears to be timestamps (but could also be interpreted as durations).

For example, if I type "3:05" into an empty cell in a new LibreOffice sheet, it's instantly changed to "03:05:00" (which means the 3 is interpreted as hours and the 5 is interpreted as minutes.)

Ofc for the non-Excel apps, one could give them a pass because they try to be as compatible with Excel as much as possible, or it could be because that's what makes the most sense to the implementers, but that's the reality of the implementations, regardless of the reason. 

I don't even blame Excel. It's just as reasonable for Excel (and others) to treat "3:05" as hh:mm as it would be to interpret that as mm:ss. One could even say it's more reasonable to assume hh:mm, since I think these are really supposed to be timestamps and not durations (although they can be treated as durations in some limited cases), and a timestamp of hh:mm seems like it would be more common than a timestamp of mm:ss (which would really mean 00:mm:ss if it's actually being interpreted as timestamp).

But 3:05.1 is unambiguously minutes, seconds, and fractions of seconds.

So I think it's objectively wrong for Garmin to output a lap time of 3 minutes and 5 seconds as "3:05" and to also output a lap time of 3 minutes and 5.1 seconds as "3:05.1", because even though those look similar to human eyes, to pretty much all the spreadsheet apps, they will be interpreted very differently (3 hours and 5 minutes vs 3 minutes and 5.1 seconds).

Again if I want to do math (like summing or averaging) of the following times in an Excel/Google Sheets sheet, it just won't work as expected:

3:00
3:05.1
2:55
3:01

But Garmin's lap export produces numbers like this all the time.

Whether or not it's Excel's "fault" for parsing times that way, it's up to Garmin to output data that's useful with the tools that users commonly use, like Excel, Sheets and Numbers. I'd guess that the number of Garmin users who use R to analyze CSV exports.

Also, it's not the only example of Garmin CSV output which is non-normalized (i.e. the output can be interpreted by a human, but it's not good for automation or number-crunching). It's just the only example I had that's handy.

Others have pointed out that the format of the activity list export changes every now and then, which breaks people's scripts.

Look I could find a million examples of this kind of stuff, but I think most ppl agree Garmin software isn't great. 

ashtermet said:

Garmin software bad you say?

Yeah I mention forum issues all the time. Garmin didn't make this forum platform but they chose it a few years ago when they migrated off an even worse platform. At the time I begged them to use a modern platform like NodeBB (which has been around for well over 10 years at this point and is used by some of the few corporations and grassroots communities which still bother to have forums), but nope, they chose this platform which is so old that it has its own broken implementation of emojis instead of using emoji support built into the client (like Windows, macOS, iOS, or Android), since the platform is from a time when such built-in emoji support was rare.

The common thread is that Garmin is bad at UI/UX. They just don't seem to be good at providing great user experiences at all. (Although they have been improving things in the watch UI over the the years.)

flowstate said:

I think most ppl agree Garmin software isn't great.

Well, I agree with that.
With regard to Excel etc though, I think you're right that other non-excel spreadsheets are forced to copy the implementation details of excel so that they don't produce different results.

They could solve easily solve it by having an export to xlsx option with the data-types correctly specified, but they're too busy removing working functionality.

ashtermet said:

They could solve easily solve it by having an export to xlsx option with the data-types correctly specified, but they're too busy removing working functionality.

Yeah tbh this is a problem I've run into in my day job, too.

Our app had a feature to export certain finance-related data to CSV, but the end user didn't like the way some of it was interpreted by Excel and blamed us.

It turned out that the only way to really make them 100% happy would be to export to XLSX so we could specify the correct types in the output, as you said.

After all CSV is just delimited text, and it isn't even a real standard. It's almost more useful as human readable output then it is as machine readable output, which goes back to what I said above about how Garmin seems to only care about the human readable aspect of their CSV export.

The nice thing about CSV is it can be opened by many different apps, and doesn't tie you to Excel (although ofc most other spreadsheet apps can open XLSX).

I also think end users don't really understand (or care) about all the little nuances of how CSV is interpreted by apps. Saw a thread about a certain Garmin CSV import format in these forums with some all-time bangers:

- American user questioning why YYYY-MM-DD format should be used for dates, exclaiming that they've never seen "European" date format used like that anywhere. The irony is that YYYY-MM-DD is an international standard and it's literally the only unambiguous date format in existence. Canada is probably in the worst situation with regards to this stuff, since our old date format is DD/MM/YY(YY) but we often copy the American format of MM/DD/YY(YY), so when you see a date like 03/04/2026 on a Canadian document, it's completely ambiguous. Our actual standard is YYYY-MM-DD, but idk how many normies actually use it. Normies are more likely to write the date out like "March 4, 2026".

- Other users claiming that either values shouldn't be enclosed by double quotes, or that double quotes change the meaning/type of the field (neither is true)

But in the case of lap CSV exports, I blame Garmin completely, as they should know better.

ashtermet said:

data-types correctly specified

Sure but if they could do that, they could also normalize the data that they do export to CSV so it's interpreted consistently by apps like Excel.

Unless ofc they don't care.

It's kinda like how people complain that to export the summary of their entire activity list in the Connect website, they have to (infinite) scroll all the way to the bottom of the activity list, which could take forever if you have a few years of activities.

(I could post endless paragraphs about how bad their implementation of infinite scroll is in the activity list, but I won't. I will say that I built a much better proof of concept using AgGrid in literally 5 minutes, which demonstrates scrolling through a list of 10,000 items in a few seconds (ofc without loading/rendering the entire list at once). Contrast with Connect's activity list, where scrolling through a few hundred activities takes several minutes. It's bad enough that if I want to see a race from 2023, I'll do anything but scroll through Connect's activity list.

ashtermet said:

but they're too busy removing working functionality.

Yeah not to mention never fixing/improving the stuff that never worked properly in the first place.