Support in-app setting for date/time format 🌍

Comments: 25

• 21 Jul, '21
  Kostas

  If "in-app setting for date/time format" is not likely to be implemented, I think that the Windows GK version should at least pull the date format directly from "Date and time formats" where it is stored for all apps to use. The current method outlined in https://support.gitkraken.com/known-issues/date-format/ that needs us to change our Windows configuration is not very helpful, at least not for all nationalities. I prefer to have my Windows GUI in English and still have GK showing dates in my region's date format, just as most other Windows apps do.
  
  I hope you will consider it and thanks for a great product.

• 11 Aug, '21
  TheAndrey

  I also miss this setting. Now I have a format only with numbers without leading zeros :(
  I want to have the letter names of the months.
  Also I want see original commit date with timezone (like a git log) same as tip with author's E-mail on hover.

• 29 Aug, '21
  Vladislav Javadov

  Just sent feedback about missing leading zeroes. I want to see timezones too, along with local time: 22.10.2019 19:14:09 (22.10.2019 09:14:09 -0700)

• 17 Sep, '21
  Joey Kelroy Admin

  "Allow dd/mm/yyyy and 24-hour format for timestamps" (suggested by Lars Refsgaard on 2021-09-17), including upvotes (1) and comments (0), was merged into this suggestion.

• 05 Nov, '21
  Ief Cuynen

  On mac the date is always shown in US format MM/DD/YYYY independent of my regional settings DD/MM/YYYY
  Even explicitly setting the correct format for gitkraken in the regional settings does not work.
  The date was shown correctly until version 7.5.0
  I contacted support for the same issue in January 2021 but still no fix till today.
  To be very honest, it bothers me a lot.

• 15 Dec, '21
  Kenneth Siewers Møller

  Every other git client I've ever used could figure this out. For some reason, GitKraken insists on doing this wrong. There has been hundreds of complaints about this, but still to this date, nothing has happened.
  Time and time again has the official "solution" been to change Windows language, which makes no sense for engineers.
  All engineers I've ever known has the Windows language set to en-US but the region set to whatever country they live in (in my case Denmark).
  Apparently, GitKraken only looks at the Windows language and ignores the regional format, which makes zero sense to me.
  
  What is the point of regional settings, if applications are not using it?
  
  I don't necessarily want GitKraken to have custom settings for changing the regional format, but at least use the system regional formats please.

• 22 Dec, '21
  Michal Bartak

  It's not only WIndows.
  On Linux (Fedora 35, Ubuntu 21) it ignores system settings and apply US formatting.
  
  BTW official pages https://support.gitkraken.com/known-issues/date-format/ say that on linux / macos the format is being adopted to system settings. We know it's not true.

• 31 Jan, '22
  Tibo

  It also ignores macos settings (tested with gitkraken 8.2.1 and macos 12.1)

• 08 Feb, '22
  Tim

  macOS user here too - Gitkraken displays commit dates with mm/dd/yyyy instead the system dd/mm/yyyy. It would be really nice to get this right

• 09 Feb, '22
  Cameron Tacklind

  This is a larger JavaScript issue. According to ECMA, what `Date#toLocaleDateString()` returns is implementation dependent. So it should respect the host's settings but no popular implementations support it. The main reason for this, I think, is because most implementations pass this job off to the de facto standard internationalization library ICU, which itself is having trouble implementing this feature: https://unicode-org.atlassian.net/browse/ICU-111
  
  In the C version of the library, there is a compatibility flag ("@compat=host") for locales on Windows that can be set to enable looking this up from the host but, as far as I can tell, that flag is filtered/prevented in JavaScript implementations before ICU can ever use it, let alone how unstandardized it is.
  
  This affects Node.js and Browsers equally.

• 21 Mar, '22
  Dan Ørjan Merged

  in the comitt graph i would like the clock to show in 24 hours, not am/pm

• 21 Mar, '22
  Jonathan Admin

  "24 hours clock option" (suggested by Dan Ørjan on 2022-03-21), including upvotes (1) and comments (0), was merged into this suggestion.

• 23 May, '22
  Thomas Michiels

  what is also an option, is instead of using the default datetime for a language/region, is using the windows format settings. I have my desktop set in english, but Windows is configured to use Dutch formats, i do not want to change my whole desktop to Dutch just to see GK datetimes correctly, while most other apps use these settings perfectly fine.

• 07 Jul, '22
  Seb U.

  +1
  Our shop is on ISO8601 standard, but the UI does not do that. Have to admit, a bit frustrating in 2022. [Using OS settings would be great. Or custom setting in Kraken - either way is fine by us.]

• 

  18 Aug, '22
  Paul Spain Merged

  The date format in the screenshot below is MM/DD/YYYY.
  
  This works fine and dandy in the USA, but not elsewhere - like Australia or Europe (DD/MM/YYYY).
  Please extend your configuration to allow for localisation/localization of displayed dates.
  
  We have to make allowances for the US all the time. It would be appreciated if you thought about the rest of the world occasionally.

• 18 Aug, '22
  Jonathan Admin

  "Please add support for localised/localized date formats" (suggested by Paul Spain on 2022-08-18), including upvotes (1) and comments (0), was merged into this suggestion.

• 06 Sep, '22
  Natalie Fearnley

  I use ISO8601 but there appears to be no way to force git kraken to respect this on Linux. The official documentation states to set the LANG or LANGUAGE variables. But set them to what?
  
  I have no idea what GitKraken is doing with this locale data, or how it processes it, so I cannot determine what I need to set it to in order to get ISO8601 style dates.
  
  As a temporary workaround while we wait for the in-app date setting to be implemented, please provide either:
  1. A list of available locales and what their date formats look like.
  or
  2. The method used to turn the locale into date. For instance, if we knew that Date.toLocaleDateString() was used, we could pick the appropriate locale.

• 26 Sep, '22
  andre

  +1 upvote, allow specify custom time format in preferences. I have en-IE on ubuntu and on windows but I am getting en-US format (with am/pm).

• 15 Nov, '22
  Thomas

  this is such an easy change. How can they take so long to decide to implement this...

• 24 Nov, '22
  ThePiachu

  Please implement this. Seeing middle-endian date formats just because my computer is in a shitty country is just bad. I don't know what magical settings I need to apply to make GitKraken give me my beloved ISO-8601 date format, and I'm not switching my region settings to China just to get it!

• 31 Jan
  HubertNNN

  I found a workaround.
  You have to edit `/usr/share/applications/gitkraken.desktop` file and change the line that starts with `Exec=` into
  ```
  Exec=env LANG=en_UK /usr/share/gitkraken/gitkraken %U
  ```
  (add `env LANG=en_UK` to the beginning of command and leave the rest unchanged)

• 10 Feb
  JohnS

  This date format does not even work in the US. People that work for international firms need a date format that is unambiguous like yyyy-mm-dd.
  
  The m/d/yyyy for the commit details is continuous confusion. It is hard to believe that this cannot be configured. There are a number of comments on Electron boards complaining about this so it may be a problem there. Regardless, there should be a work around.

• 28 Feb
  Andrew Thomas Blake

  +1 for ISO8601
  
  US and UK date formats are equally idiotic -- how can we still be in the situation where unless you happen to know which system is being used, for -- what is it? -- 132 days out of the year we are shown a date which doesn't tell us the date
  
  If you want GK to be used outside the US, rather than allowing other equally idiotic date formats to be used in addition to the US one, I think ISO8601 should be used universally -- then no one can be confused
  
  plus of course lexical = chronological

• 07 Mar
  Marek P.

  it is still not resolved as of 2023. This is absolutely ridiculous! Most engineers use en-US system for convenience and compatibility with software, but ISO Y-m-d format. How stubbornly git Kraken defends this nonsense is astonishing.

• 09 Mar
  Cameron Tacklind

  Formatting dates in the system dependent locale is a major problem in the JavaScript world. The core of the issue is that this particular part of the library is handled by many different players. This issue is present in many browser based webmail clients, and even in Chrome itself.
  
  Specifically, JavaScript's `Date.prototype.toLocale*String()` *should* handle this. The JavaScript spec allows that function to return an OS or language-sensitive representation of the date/time... So where does that come from?
  
  Looking around, and skipping some steps, it seems that most JavaScript runtimes depend on ICU for internationalization and localization functions, which includes formatting dates. ICU has a long standing feature request to respect the OS'es specific localization selections: https://unicode-org.atlassian.net/browse/ICU-111
  
  So, unless Atlassian wants to implement their own internationalization and localization unicode library extension, we get to wait until ICU addresses this issue