The following settings have been implemented for the next release:

• enable/disable relative date formatting #finally
• choose to use system default or matching locale for the date field

We've also expanded the test cases to include those itemized in this ticket.

Not respecting the date/time format the user has configured in preferences is among the biggest fails you can make as an macOS app developer, seriously. It's so easy to get a DateFormatter from the system with the style the user has configured, it's one line of code. This bug has been open for almost ten month, ten month for a bug, that can be fixed by one line of code.

Oh, and don't forget the "Log View" as well, when logging history of a file (it also has a date column).

Come on, guys!

Is there some progress on this?

Today I did a huge mistake when reviewing log and thinking "12:XX AM" is a day. But turned out it's just after the midnight! Please, give us an option to set 24 hour format – all the other world use it!

Update: A quickest workaround for this would be to add another language, say “English (U.K.)” along “English (U.S.)” that would have 24 hour formatting.

Pavel Alexeev and Eric Scouten are right here. I too would prefer do have language and localization configured separately. Having to switch between command line tools and a bunch of GUIs and IDE integrations for git, it is far easier to remember the English wording for all the actions than to memorize the, sometimes weird, translations into German (not to mention that there may be different translations for the various apps). But in any case I want to keep the localization to German.

As it is already inconsistent (see my previous comment with screenshots), it should be fixed anyways. So why not just add a config switch to choose for the application language and the date format separately?

It's not a matter of complexity (I know how, I made the original change) - its reasoning are in the prior comment. Until we decide on a different behavior or add an option comments aren't going to change much. Votes count, make sure to do so.

Note: we're not using hardcoded date formats either, it's a combination of NSDateFormatter options along with the locale.

Is there any progress on this issue?
I've been using an old version of SourceTree with normal date formatting, but now you say it has security flaw and must be updated. So I updated and the issue is back for me

It's not hard to make, just use built-in date style, instead of hardcoded one:

[commitDateFormatter setDateStyle:NSDateFormatterLongStyle];

Even worse: The display of date and time in the list view and the details is inconsistent.

I chose "English (U.S.)" as language in the SourceTree settings:

That changes the date/time in the history list view to English and 12 hour format, but leaves the date/time in the details pane to the system standard of German an 24 hours format:

Pavel, this is my point exactly. I only "chose" U.S. English as my language+localization because SourceTree didn't give me a more appropriate choice. (One could envision a "use system time and date format" checkbox next to the localization popup.) I didn't care about that lack of expressive power (indeed, I didn't even notice it) until 2.4.0 when the team "improved" the localization compliance to follow the language popup menu for date and time formatting and thus lost the ability to honor customizations in Date and Time preferences.

About my use of "improved" in quotes: I completely understand the desire to provide language-appropriate formatting. That is an appropriate and laudable goal, but there has also been something lost in pursuit of that goal which the team has yet to acknowledge.

There are two different things – language and localization.

The fact that I use English as my primary language for development, doesn't mean I use 12-hour format.

If you decide to make your own language selection in settings, it would be great to have independent localization settings as well. Or at least simple 12/24 hours switch.

Reverted to 2.3.2 as well.

Just found a laptop that still has 2.3.2 installed. I played around with other languages briefly and I see the issue you're trying to avoid. "Yesterday, 11:40" looks bad when you're in Spanish. But it did honor my localization customizations (regardless of language).

While I understand what you're trying to accomplish, I stand behind my statement that this is a regression. Most apps (consider Finder, for example) manage to respect the actual date & time settings on the machine.

I'll revert to 2.3.2 on my main laptop for now.