[Bug] Editing gear decreases first use date

Problem:

The first use date, that cannot be edited by the user, is decreased by one day every time the gear is edited and saved.

Expected Behavior:

I'd expect the date to not be changed by the edit form if I edit the gear.

Steps to reproduce:

  • Create a new gear and add a First use date. Press save to create it
  • Click on the small drop down and press edit
  • Observe how the first use date decreased by one day
  • Press save to save it
  • Repeat by pressing edit and observe how the date moved back another day

Screenshots:

Create the gear:

Edit the first time:

Edit the second time:

Top Replies

All Replies

  • After trux mentioned it as a workaround for people who want to change the date I tried the dev tools as well. But it seems like there's something wrong on their backend as well. Or one has to make changes to the JS code there as well.

  • After trux mentioned it as a workaround for people who want to change the date I tried the dev tools as well. But it seems like there's something wrong on their backend as well. Or one has to make changes to the JS code there as well.

    I'd argue that part is working as intended given that the field is supposed to be disabled. It's just ironic that you're running into this bug given that the field can't otherwise be edited.

    I've seen similar behavior on other pages in Connect - when a field is disabled, it doesn't help to enable it or manually change the value in the dev tools. (As a matter of fact, if you manually change the value, it's not even reflected on the page.)

    There's probably some js that connects the visible fields to the "real" fields that are submitted when you save the form, or something like that, and it's probably not going going to copy the value over when a field is disabled.

    I guess what could be happening is that the original value is still being submitted (even though you can't edit it), and it's this original value which is subject to whatever time zone bug is in effect here.

  • I can reproduce the "feature", and am also located in the EU, so it indeed looks like a Time Zone related issue. Would be interesting to try it also shortly before and after the midnight, to see whether there is some threshold.

    However, I find it rather useful, and it does not harm anything. You can see when you truly used the gear in the stats, so the date in the gear settings is in fact unimportant - just avoiding to add older activities to the gear.

  • BTW I was able to easily recreate your problem by changing my device time zone to UTC+2 (Central European Summer Time) or UTC+1 (British Summer Time). But when I tried UTC+0 (Reykjavik), the problem went away.

    So it seems like this problem affects every time zone where the UTC offset is greater than 0.

    This makes sense if all dates are interpreted/stored in terms of UTC timestamps, but they're *calculated* / generated in terms of the local time zone at midnight (which is entirely feasible since that's how most date pickers work.)

    00:00 2024-08-25 (UTC-4) = 04:00 2024-08-25 (UTC)

    00:00 2024-08-25 (UTC+0) = 00:00 2024-08-25 (UTC)

    00:00 2024-08-25 (UTC+1) = 23:00 2024-08-24 (UTC)

    Since the form field itself apparently only stores the date and not the time, every time you open the form, the date will be decremented by one day. There has got to be something akin to a hidden form field which is initialized to the same value as the visible form field, and is submitted when you save the form. (Not literally a hidden form field, but more likely some js variables that we can't even access by inspecting the DOM.)

  • I find it rather useful, and it does not harm anything

    I have to disagree. It's unintended behavior. If Garmin wants to give users the ability to edit the first use date, this is obviously not the way to go about it.

  • It's unintended behavior

    Unintended and welcome Slight smile

  • Yeah, I guess 2 wrongs do make a right: when an obscure / overly restrictive / unnecessary "feature" like gear first use date collides with an obscure time zone related bug that doesn't affect America so Garmin has zero chance of noticing it.

  • Anyway I would contact Garmin support with this problem if you want to see it fixed. Or maybe edit your gear in the Connect app? Idk if the same problem exists there. EDIT: I just tried it and the bug doesn't seem to exist in the app.

    If this problem really bothers you, and you still want to use Connect website, you could:

    - change time zone in system settings

    - open new browser instance (use a "spare" browser that isn't currently open - e.g. if you normally use firefox, use chrome for this)

    - change gear in Connect

    - close spare browser

    - change time zone back

    The trick here is that browsers typically don't pick up changes in the system settings such as time zone or date/time format unless you restart the browser. So any browser that's currently open will be unaffected by this temporary change in time zone, but the spare browser that you open after changing the time zone will pick up the change.

    That's exactly how I tested this problem.

  • Anyway I would contact Garmin support with this problem if you want to see it fixed. Or maybe edit your gear in the Connect app? Idk if the same problem exists there.

    I mean I posted them here because garmin said here that issues with connect web should go into this forum. I might contact them directly at some point, though.

    If this problem really bothers you, and you still want to use Connect website, you could:

    I initially tried to spoof the time zone in the browser, that didn't work. After you mentioned setting the devices timezone I tried that and was able to switch between the two behaviours. I didn't even need to restart the browser, reloading the page was enough for me. Thanks for the tips!

  • Fair, I didn't try reloading the page haha.