Hi there,
I’m based in Australia and we use dd/MM/yyyy as a format for dates. Unless I’m missing something I cannot find a setting for the iOS app to display dates in this format, is there anywhere I can set this?
Thanks,
Joseph.
8 Likes
Hey! There’s no function to change this yet, although its a feature we’re currently working on that will be incorporated into one of the upcoming few releases. Hold tight!
8 Likes
Same format in Europe as well.
Awesome - look forward to it. Thanks for the reply!
1 Like
Can we please standardise on ISO8601 / yyyy-MM-dd as that removes any ambiguity?
6 Likes
The simple solution is dd-mmm-yyyy.
26-May-2021.
3 Likes
maybe you can ask all of Europe and Australia to do that for you as well… its certainly not any agreed standard here. Option to set what you like is the way to go.
I’ve already set my region settings! I should not have to specify my preferred datetime format for every fricking app. It should just pick up the region formatting from the iOS APIs. 
I want my temperatures in celsius, my calendars in Gregorian, and my times in 24hr. Thank you.
This is basic stuff and it’s frustrating that, not just TR, but so many other companies (looking at you Garmin) manage to screw this up.
[rant over]
10 Likes
I came across this bug on the web career page. I did a workout outside with just HR data. I was asked if I wanted to use estimated HR TSS. I agreed then the code threw a wobbly because my date of birth in my profile was in European format.
Having worked with date and time formats for consumer electronics it’s not easy. The underlying date/time value should be separate from how it’s presented. MJD is a common format for dates prior to the Linux epoch or 1970-01-01.
Oh no! Can you follow up with the team at support@trainerroad.com so we can look into that issue more effectively? Thanks for reporting!
Just noticed that there’s only one English language option, “English (United States)”. Many code libraries tie things like language and date format (among other things) together so have “English (GB)” etc.
@IvyAudrain - have raised a ticket with support.
1 Like
Go on youtube, search for a guy called Tom Scott and find some of his videos about time zones, date formatting and coding. This will give you some idea of how difficult it actually is to get stuff like this right. He’s a total (awesome) geek about loads of stuff, great for wasting hours learning about things you never needed to know.
3 Likes
I work in IT and have never worked on a project that didn’t have a time related bug of some sort. This is a bit different though as the options for other formatted simply aren’t available.
1 Like
+1 for locale-based time formats!
1 Like
+1
This is a solved problem if they were using iOS-native APIs. Mac OS and its derivatives have had support for that since inception. If they used native APIs to display dates, then the format would be dictated by the system settings (that you can change in the Settings app in iOS). I used to work on the localization of then MacOS X into several languages and have chased down tons of bugs like those. Even at Apple a lot of engineers didn’t think about localizability and hard-coded many things that had to be localized.
1 Like
I’m using Android and I have this problem.
Only app on my phone that does this. So it can catch me out and confuse me momentarily. “Why is this workout from July now saying February?? Ohhh that’s right, TrainerRoad’s dates are broken.”
2 Likes
I’m sure this is a solved problem on Android, too, although I don’t have any first-hand experience. Dealing with dates and times is really a tricky problem, which is why one should use APIs if one can.
1 Like
There’s an old programming adage: anyone who thinks coding with dates and time is easy hasn’t done any.
I worked on Digital TV decoders (UK, EU & US) for nearly twenty years, the underlying representation of time is always separate from how it is displayed to the consumer. In fact all digital TV programs are broadcast with UTC timestamps even in the US, doing it any other way would be a nightmare. Typically the consumer sets up the unit with their zipcode/postcode or similar and the setup software works out which timezone they are in and what if any daylight savings should be applied. Everything like setting reminders, recordings is done under the hood in UTC.
The native apps run on the Electron stack - I’d be surprised if the problem was with that otherwise other services/programs that use it would see the same problem. I suspect that the US date format is hard coded internally.
ISO-8601 is fine but from memory the only major nations that use it are China, Japan, Taiwan and the Koreas. Has the advantage that string representations are sortable using standard character sets.
1 Like
I agree, to a non-programmer it seems like such a simple thing, but reality VERY different. However not that fussed…will changing date format make me faster…nope so minimal resources please TR!