Timestamp format should match system time format

[sunflowerspeed]

• [X] I have searched open and closed issues for duplicates

---

Description

It would be nice if timestamps on messages matched the time format used by the system. Currently, timestamps appear in US format (twelve hour + AM/PM), even though my system is set to display time in 24-hour format.

Steps to Reproduce

1. Send or receive a message using Signal Desktop for Windows.
2. Check the timestamp for the message.

Actual Result:

The timestamp reads 11:32pm, even though my system clock reads 23:32. (Note the time I wrote here is just an example.)

Expected Result:

The timestamp and system clock should both say 23:32.

Platform Info

Signal Version:

1.33.4

Operating System:

Windows 10 Home, 64 bit, version 1909 (OS Build 18363.778)

Linked Device Version:

Android version 10

[almer-t]

From a user perspective I think this is a completely reasonable thing to expect. From a technical point of view: Electron applications can't access the system local preferences directly with respect to date and time rendering (more specifically Chromium does not expose this (yet)).

For the developers, this basically depends on this issue being resolved: https://github.com/electron/electron/issues/13023#issuecomment-418581463

[sunflowerspeed]

Ah, apologies. I did search for similar issues but apparently I didn't search well enough. Thank you for pointing this out to me :-)

[almer-t]

No worries, this would have been difficult to find (as the problem is not in the Signal desktop app, but rather in a package it uses).

[scottnonnenberg-signal]

Yeah, we do have other issues tracking this, but we can keep this open for now:

• https://github.com/signalapp/Signal-Desktop/issues/2616
• https://github.com/signalapp/Signal-Desktop/issues/2938
• https://github.com/signalapp/Signal-Desktop/issues/3317

[noelleleigh]

I've been doing some digging, and I think the issue is a bit more complex than an Electron/Chromium deficiency.

https://github.com/signalapp/Signal-Desktop/blob/4811b5fd4db4c6af9aece3abcf3cd1a5e0a24b3d/ts/util/formatRelativeTime.ts#L10-L19

Moment claims to have a formatting token that is "localized" (LT), but in practice it always returns time in the format h:mm A, even if the locale is set such that a 24-hour time would be expected.

Here's some results I got from using the dev tools in Signal Desktop 1.33.4:

> navigator.language // Current system locale
"en-GB"
> timestamp.constructor.name // timestamp is a Moment object
"Moment"
> timestamp.format("LT") // "localized" time isn't localized as it should be
"8:26 PM"
> timestamp.toDate().toLocaleTimeString() // Proper localized time
"20:26:35"
> timestamp.toDate().toLocaleTimeString("en-US") // Localized time for a specific locale
"8:26:35 PM"

This doesn't cover the case of changing a locale that has a 12-hour cycle by default to a 24-hour cycle, but by using built-in JavaScript APIs, it would provide a decent locale-aware experience in most cases. If Signal wanted to add a built-in option for 24-hour cycles, that can be specified by passing { hour12: false } as the second argument of toLocaleTimeString()

References

• Date.prototype.toLocaleTimeString()
• Intl.DateTimeFormat
• Intl.RelativeTimeFormat

[furai]

Why not just let user change the locale/date format in preferences? Does it really have to be pulled from system?

[Shnub]

@furai

Why not just let user change the locale/date format in preferences?

Because the user has already set (or kept) a system-wide preference setting and has a reasonable (I'd even say trivial) expectation that apps will respect this. A Signal-specific preference setting would be a last-resort workaround if it turned out to be technically impossible to implement the proper behavior in the foreseeable future, but it is certainly not desirable.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[DrMcCoy]

This is still very much an issue and should be fixed.

[indutny-signal]

Assigned to myself to keep this open. Thanks!

[real-or-random]

Unfortunately the recent change to show absolute timestamps instead of relative timestamps (even for recent messages) made this issue appear worse. I see AM/PM all the time now.

[indutny-signal]

@real-or-random could you try the latest 5.34.0-beta.1 release and see if it is any better, please?

[real-or-random]

@indutny-signal No, it's the same:

[indutny-signal]

Oh, too bad! Sorry.

A few more questions:

• What OS are you on? (Judging by font rendering - Windows or Linux?)
• What locale are you on? (What language is your OS in?)
• Could you try running this in your Chrome or Firefox's dev tools console: new Date().toLocaleTimeString([], { hour: 'numeric', minute: '2-digit' })

Thank you!

[real-or-random]

I'm on Linux.

> env | grep "LANG\|LC_"
LC_MESSAGES=en_US.UTF-8
LC_CTYPE=de_DE.UTF-8
LC_TIME=de_DE.UTF-8
LC_NUMERIC=de_DE.UTF-8
GDM_LANG=en_US.utf8
LC_MEASUREMENT=de_DE.UTF-8
LANGUAGE=
LC_MONETARY=de_DE.UTF-8
LC_ADDRESS=de_DE.UTF-8
LC_NAME=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_COLLATE=de_DE.UTF-8
LANG=en_US.utf8
LC_PAPER=de_DE.UTF-8

Could you try running this in your Chrome or Firefox's dev tools console: new Date().toLocaleTimeString([], { hour: 'numeric', minute: '2-digit' })

Gives 12 h output.

My problem is exactly the one on https://github.com/signalapp/Signal-Desktop/issues/3317 but this may be hard to solve because browsers ignore LC_TIME and js doesn't have a concept for different locales for different things. (MESSAGES vs TIME for example.) And the same seems to be true on Windows...

I wonder if a setting is a good idea. If not, I fear there's not much that can be done.

Setting LC_MESSAGES=en_DK.UTF-8 for signal is a workaround for me. (Or en_GB should do, too.)

[indutny-signal]

Oh, I see. So the issue here is that we don't respect LC_TIME. Gotcha. Thank you!

[PeteSapai]

@Shnub

Why not just let user change the locale/date format in preferences?

Because the user has already set (or kept) a system-wide preference setting and has a reasonable (I'd even say trivial) expectation that apps will respect this.

That would be reasonable if Signal actually respected the locale. Also, that argument fails as the user can also set a system-wide dark or light theme, yet there is an option to set a different one in Signal. If you can override a system-wide theme, then why not add an option to override system-wide time format? (Especially since Signal isn't able to respect said time format.)

A Signal-specific preference setting would be a last-resort workaround if it turned out to be technically impossible to implement the proper behavior in the foreseeable future, but it is certainly not desirable.

This issue is now over 2 years old. Maybe it is time to implement this as a workaround?

Edit: alternatively, if it is so impossible to implement and you don't want to add a simple much requested feature that solves the problem, why not set the default to the better system, i.e. 24H?

[DrMcCoy]

All this bike-shedding about the "proper" way to implement this, while nothing is being done and non-USians are left high and dry

[ramaboo]

This bug is super annoying for 24 hour clock users! Either make it a setting for figure out how to get the system time settings.

[Shnub]

This bug is now considered as needing an upstream change (which I gather is short for "sorry, we can't do anything about this"). I'm not a programmer, but didn't @noelleleigh identify a possible way to implement properly localized time with available means (https://github.com/signalapp/Signal-Desktop/issues/4252#issuecomment-627696983)?

timestamp.toDate().toLocaleTimeString() // Proper localized time "20:26:35"

That's exactly what we need, and apparently achieved with Signal's dev tools.

If I'm mistaken and this is really only solvable by changes outside of Signal's own code, then by God please just make it a manual setting. This is a basic usability issue; the vast majority of your user base can't tell at a glance when a message was sent because it's in an unfamiliar format! It's almost like having to mentally adjust for a different time zone. I'd say if that can't be fixed in several years then it's reasonable to implement, as I put it in my previous comment, a last-resort workaround so that 24 h clock users can finally read timestamps in Signal Desktop.

[indutny-signal]

I believe we already use this function: https://github.com/signalapp/Signal-Desktop/blob/85c8ff7/ts/util/timestamp.ts#L124-L127 . I think the issue here is that environment variables are used to override app locale and that the timestamp ends up being rendered in a locale that is different from what is set up in the env.

[max-rosenfors]

I don't mean to sound mean, but why is the US standard considered holy in this regard? Is there a overwhelming number of US-based users compared to non-US users? In my opinion, if it is difficult to change to user system-preferences, just use the 24 hour format. I am perfectly confident in saying most if not all US-based people will be able to understand the 24 hour format, whilst almost everyone outside the US gets the AM/PM distinction mixed up all the time.

Alternatively, if you insist on keeping the US-standard, maybe you can give us a "(hours ago)" next to the timestamp. That will help all non-US users greatly.

[PeteSapai]

Sooo... any update on this?

It's ridiculous that Signal decides to just completely ignore system settings and use this weird, obscure time format that uses letters in stead of numbers to indicate the time of day. Ffs, it's been over 2 years and 4 months (is that 9 A.M.s and 17 inches fahrenheit in US time?) since this was reported, how is it not fixed yet?!?

[squeak9]

I couldn't find the setting for this and thought "oh changing the language to en-GB or en-CA should fix this" but it turns out you can't change the language for this app without changing the OS language.. https://support.signal.org/hc/en-us/articles/360049188372-Language-Options#desktop

Just add a setting if detecting it automatically is such a hurdle.

[crix-lab]

Adding my plea. Please fix it, it's very annoying for 24h format users.

[maymage]

Using the flatpak version.. dates and times are in the correct format, in particulr 24h.. So I'm not sure, what's the issue here. Can this be platform dependent?

[GaetanLepage]

Still an issue. It would be great for Signal to be locale (LC_*) compliant :)

[filikun]

EDIT: Changing the OS language to English (UK) solved it for me. Maybe it would be better if Signal took after what settings you are using in the Regional format menu instead of locale?

Oh, too bad! Sorry.

A few more questions:

• What OS are you on? (Judging by font rendering - Windows or Linux?)
• What locale are you on? (What language is your OS in?)
• Could you try running this in your Chrome or Firefox's dev tools console: new Date().toLocaleTimeString([], { hour: 'numeric', minute: '2-digit' })

Thank you!

Windows 11 Version 10.0.22621 Build 22621

Though Windows display language is set to English (United States) the regional format is English (Sweden).

new Date().toLocaleTimeString([], { hour: 'numeric', minute: '2-digit' })
12:12

[Stodeus]

Look like this issue is sill present with version 6.14.0 AM/PM time is not much used beside US, it would be nice to have the 24h version instead.

[norstbox]

@indutny-signal It looks like Electron has finally come up with a suitable API, at least for Mac and Windows. From the app.getSystemLocale() description:

Therefore, this API can be used for purposes such as choosing a format for rendering dates and times in a calendar app, especially when the developer wants the format to be consistent with the OS.

[alametti]

This issue still appears to be active in production version 6.27.0 on Ubuntu 22.04.2 LTS, despite the following environment variables:

env | grep "LANG\|LC_"
LANGUAGE=en_CA:en
LANG=en_CA.UTF-8
LC_TIME=C.UTF-8

[scottnonnenberg-signal]

@alametti Can you provide your debug log, and more detail about what you're seeing vs. what you expect to see?

[alametti]

@scottnonnenberg-signal

What I see

The timestamp of messages on signal-desktop that are over 1 hour old is displayed as [12hh]:mm [a/p].m.
I may be misremembering but I seem to recall this was not the case before.

What I expect to see

The timestamp of messages over 1 hour old should be displayed as [24hh]:mm, as is the case for all other applications in my desktop environment that respect the time locale environment variables

System info

$ uname -srvmo
Linux 6.2.0-26-generic #26~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Jul 13 16:27:29 UTC 2 x86_64 GNU/Linux
$ env | grep "LANG\|LC_"
LANGUAGE=en_CA:en
LANG=en_CA.UTF-8
LC_TIME=C.UTF-8

Signal log

$ signal-desktop --debug
Set Windows Application User Model ID (AUMID) { appUserModelId: 'org.whispersystems.signal-desktop' }
NODE_ENV production
NODE_CONFIG_DIR /opt/Signal/resources/app.asar/config
NODE_CONFIG {}
ALLOW_CONFIG_MUTATIONS undefined
HOSTNAME undefined
NODE_APP_INSTANCE undefined
SUPPRESS_NO_CONFIG_WARNING undefined
SIGNAL_ENABLE_HTTP undefined
userData: ~/.config/Signal
config/get: Successfully read user config file
config/get: Successfully read ephemeral config file
making app single instance
{"level":30,"time":"2023-08-07T16:47:57.350Z","msg":"app.ready: preferred system locales: en-CA, en"}
{"level":30,"time":"2023-08-07T16:47:57.350Z","msg":"locale: Supported locales: af-ZA, ar, az-AZ, bg-BG, bn-BD, bs-BA, ca, cs, da, de, el, en, es, et-EE, eu, fa-IR, fi, fr, ga-IE, gl-ES, gu-IN, he, hi-IN, hr-HR, hu, id, it, ja, ka-GE, kk-KZ, km-KH, kn-IN, ko, ky-KG, lt-LT, lv-LV, mk-MK, ml-IN, mr-IN, ms, my, nb, nl, pa-IN, pl, pt-BR, pt-PT, ro-RO, ru, sk-SK, sl-SI, sq-AL, sr, sv, sw, ta-IN, te-IN, th, tl-PH, tr, ug, uk-UA, ur, vi, yue, zh-CN, zh-HK, zh-Hant"}
{"level":30,"time":"2023-08-07T16:47:57.350Z","msg":"locale: Preferred locales:  en-CA, en"}
{"level":30,"time":"2023-08-07T16:47:57.352Z","msg":"locale: Matched locale: en"}
{"level":30,"time":"2023-08-07T16:47:57.369Z","msg":"locale: Text info direction for en: ltr"}
{"level":30,"time":"2023-08-07T16:47:57.370Z","msg":"app ready"}
{"level":30,"time":"2023-08-07T16:47:57.370Z","msg":"starting version 6.27.1"}
{"level":30,"time":"2023-08-07T16:47:57.371Z","msg":"media access status [object Undefined] [object Undefined]"}
{"level":30,"time":"2023-08-07T16:47:57.372Z","msg":"got fast theme-setting value dark"}
{"level":30,"time":"2023-08-07T16:47:57.373Z","msg":"got fast theme-setting value dark"}
{"level":30,"time":"2023-08-07T16:47:57.373Z","msg":"got fast spellcheck setting false"}
{"level":30,"time":"2023-08-07T16:47:57.373Z","msg":"getSystemTraySetting had no flags and did no DB lookups. Returning DoNotUseSystemTray"}
{"level":30,"time":"2023-08-07T16:47:57.373Z","msg":"Initializing BrowserWindow config: {\"show\":false,\"width\":1001,\"height\":1393,\"minWidth\":300,\"minHeight\":200,\"autoHideMenuBar\":false,\"titleBarStyle\":\"default\",\"titleBarOverlay\":false,\"backgroundColor\":\"#121212\",\"webPreferences\":{\"devTools\":false,\"spellcheck\":false,\"enableBlinkFeatures\":\"CSSPseudoDir,CSSLogical\",\"nodeIntegration\":false,\"nodeIntegrationInWorker\":false,\"sandbox\":false,\"contextIsolation\":true,\"preload\":\"[REDACTED]/preload.bundle.js\",\"backgroundThrottling\":true,\"enablePreferredSizeMode\":true,\"disableBlinkFeatures\":\"Accelerated2dCanvas,AcceleratedSmallCanvases\"},\"icon\":\"[REDACTED]/images/signal-logo-desktop-linux.png\",\"x\":154,\"y\":870}"}
{"level":30,"time":"2023-08-07T16:47:57.387Z","msg":"spellcheck: user locales: [\"en-CA\",\"en\"]"}
{"level":30,"time":"2023-08-07T16:47:57.387Z","msg":"spellcheck: available spellchecker languages: [\"af\",\"bg\",\"ca\",\"cs\",\"cy\",\"da\",\"de\",\"de-DE\",\"el\",\"en\",\"en-AU\",\"en-CA\",\"en-GB\",\"en-GB-oxendict\",\"en-US\",\"es\",\"es-419\",\"es-AR\",\"es-ES\",\"es-MX\",\"es-US\",\"et\",\"fa\",\"fo\",\"fr\",\"fr-FR\",\"he\",\"hi\",\"hr\",\"hu\",\"hy\",\"id\",\"it\",\"it-IT\",\"ko\",\"lt\",\"lv\",\"nb\",\"nl\",\"pl\",\"pt\",\"pt-BR\",\"pt-PT\",\"ro\",\"ru\",\"sh\",\"sk\",\"sl\",\"sq\",\"sr\",\"sv\",\"ta\",\"tg\",\"tr\",\"uk\",\"vi\"]"}
{"level":30,"time":"2023-08-07T16:47:57.387Z","msg":"spellcheck: setting languages to: [\"en-CA\",\"en\"]"}
{"level":30,"time":"2023-08-07T16:47:57.392Z","msg":"MainSQL: updateSchema:\n  Current user_version: 86;\n  Most recent db schema: 86;\n  SQLite version: 3.39.4;\n  SQLCipher version: 4.5.3 community;\n  (deprecated) schema_version: 371;\n"}
{"level":30,"time":"2023-08-07T16:47:57.622Z","msg":"got fast theme-setting value dark"}
{"level":30,"time":"2023-08-07T16:47:58.047Z","msg":"got fast spellcheck setting false"}
{"level":30,"time":"2023-08-07T16:47:58.052Z","msg":"System tray service: created"}
{"level":30,"time":"2023-08-07T16:47:58.052Z","msg":"System tray service: updating main window. Previously, there was not a window, and now there is"}
{"level":30,"time":"2023-08-07T16:47:58.052Z","msg":"System tray service: rendering no tray"}
{"level":30,"time":"2023-08-07T16:47:58.052Z","msg":"Begin ensuring permissions"}
{"level":30,"time":"2023-08-07T16:47:58.053Z","msg":"Ensuring file permissions for 4 files"}
{"level":30,"time":"2023-08-07T16:47:58.053Z","msg":"Finish ensuring permissions in 1ms"}
{"level":30,"time":"2023-08-07T16:47:58.055Z","msg":"main window is ready-to-show"}
{"level":30,"time":"2023-08-07T16:47:58.055Z","msg":"showing main window"}
{"level":30,"time":"2023-08-07T16:47:58.055Z","msg":"System tray service: rendering no tray"}
{"level":30,"time":"2023-08-07T16:47:58.566Z","msg":"Updating BrowserWindow config: %s {\"maximized\":false,\"autoHideMenuBar\":false,\"fullscreen\":false,\"width\":1001,\"height\":1393,\"x\":154,\"y\":907}"}
{"level":30,"time":"2023-08-07T16:47:58.567Z","msg":"config/set: Saving ephemeral config to disk"}
{"level":30,"time":"2023-08-07T16:47:58.568Z","msg":"config/set: Saved ephemeral config to disk"}
{"level":30,"time":"2023-08-07T16:47:58.755Z","msg":"MainSQL: slow query getAllStories duration=604ms"}
{"level":30,"time":"2023-08-07T16:47:58.842Z","msg":"Prevent display sleep service: allowing display sleep"}
{"level":30,"time":"2023-08-07T16:47:58.842Z","msg":"Background throttling enabled because no call is active"}
{"level":30,"time":"2023-08-07T16:47:59.304Z","msg":"updater/start: Updates disabled - not starting new version checks"}
{"level":30,"time":"2023-08-07T16:47:59.307Z","msg":"System tray service: setting unread count to 3"}
{"level":30,"time":"2023-08-07T16:47:59.307Z","msg":"System tray service: rendering no tray"}
{"level":30,"time":"2023-08-07T16:47:59.307Z","msg":"App loaded - time: 1937"}
{"level":30,"time":"2023-08-07T16:47:59.308Z","msg":"SQL init - time: 29"}
{"level":30,"time":"2023-08-07T16:47:59.308Z","msg":"Preload - time: 418"}
{"level":30,"time":"2023-08-07T16:47:59.308Z","msg":"WebSocket connect - time: 1014"}
{"level":30,"time":"2023-08-07T16:47:59.308Z","msg":"Processed count: 0"}
{"level":30,"time":"2023-08-07T16:47:59.308Z","msg":"Messages per second: 0"}

Signal version

6.27.1 signal-desktop Source: https://updates.signal.org/desktop/apt xenial InRelease

[jamiebuilds-signal]

@alametti Right now, on Linux, we're reading your locale as en-CA (English [Canada]), which resolves to a 12 hour cycle, which based on my online searches seems to be typical. As opposed to fr-CA (French [Canada]) which resolves to a 24 hour cycle.

Do you have some additional preferences on your operating system to set it to a 24 hour cycle?

[alametti]

@jamiebuilds-signal That is correct, my overall locale is en_CA, but I set my computer to use a 24-hour time format globally using the graphical settings menu (see image), as well as with the LC_TIME global locale environment variable.
Usually, LC_TIME is set to C.utf8; I tried changing it to fr_CA.utf8 to see if Signal would display dates and time in 24-hour format (and in French!). Unfortunately that did not change anything and I am still getting date and time in 12hh:mm a.m. format in the desktop application.

$ locale
LANG=en_CA.UTF-8
LANGUAGE=en_CA:en
LC_CTYPE="en_CA.UTF-8"
LC_NUMERIC="en_CA.UTF-8"
LC_TIME=fr_CA.UTF-8
LC_COLLATE="en_CA.UTF-8"
LC_MONETARY="en_CA.UTF-8"
LC_MESSAGES="en_CA.UTF-8"
LC_PAPER="en_CA.UTF-8"
LC_NAME="en_CA.UTF-8"
LC_ADDRESS="en_CA.UTF-8"
LC_TELEPHONE="en_CA.UTF-8"
LC_MEASUREMENT="en_CA.UTF-8"
LC_IDENTIFICATION="en_CA.UTF-8"
LC_ALL=
$ locale -k LC_TIME
abday="dim;lun;mar;mer;jeu;ven;sam"
day="dimanche;lundi;mardi;mercredi;jeudi;vendredi;samedi"
abmon="jan;fév;mar;avr;mai;jun;jui;aoû;sep;oct;nov;déc"
mon="janvier;février;mars;avril;mai;juin;juillet;août;septembre;octobre;novembre;décembre"
am_pm=";"
d_t_fmt="%a %d %b %Y %T"
d_fmt="%Y-%m-%d"
t_fmt="%T"
t_fmt_ampm=""
era=
era_year=""
era_d_fmt=""
alt_digits=
era_d_t_fmt=""
era_t_fmt=""
time-era-num-entries=0
time-era-entries="d"
week-ndays=7
week-1stday=19971130
week-1stweek=1
first_weekday=1
first_workday=2
cal_direction=1
timezone=""
date_fmt="%a %d %b %Y %T %Z"
time-codeset="UTF-8"
alt_mon="janvier;février;mars;avril;mai;juin;juillet;août;septembre;octobre;novembre;décembre"
ab_alt_mon="jan;fév;mar;avr;mai;jun;jui;aoû;sep;oct;nov;déc"

Presumably Signal uses only the LANG locale to determine all other locale formats and ignores global settings that may differ at either the desktop environment or OS locale levels.

[jamiebuilds-signal]

Yes, more specifically it looks like Chromium doesn't look at the LC_TIME environment variable (However, for comparison, Firefox removed support and added it back). I'm going to investigate what it would look like for us to support that. So I'm actually surprised it ever was using your preferences as is.

I'll have to see if we would be able to support every possible option for LC_TIME, but maybe since C is the result of flipping the Time format system preference on Ubuntu we could support that as a one-off thing.

For Ubuntu's system preference, is 12-hour and 24-hour the only options? Does 12-hour result in LC_TIME being unset or set to en-CA.UTF-8/something else?

[alametti]

@jamiebuilds-signal As far as I'm aware, Ubuntu's AM/PM and 24-hour formats don't change LC_TIME or any other locale settings in /etc/default/locale. I only changed LC_TIME myself after some other applications weren't using GNOME's time format. I don't know what the method to implement Ubuntu's system preference time format would be.

I just tried switching between AM/PM and 24-hour; there were no changes to LC_TIME or any other locale variables.

Perhaps I am misremembering what Signal desktop's behaviour used to be - for what it's worth, my mobile Signal app (on an Android system) correctly uses the globally defined 24-hour format despite the en_CA locale.

[PeteSapai]

How about in stead of looking for a fix, you simply implement an option to set the time format manually? (As has been asked/suggested before.) This is a 39 months old bug, maybe it's time to throw in the towel; stop pouring hours or work into trying to fix it, and spend 15 minutes on a simple workaround. (Or even easier: spend 5 minutes to just set the time format to HH:MM for everyone and be done with it.)

[Shnub]

I'll have to see if we would be able to support every possible option for LC_TIME, but maybe since C is the result of flipping the Time format system preference on Ubuntu we could support that as a one-off thing.

Please keep in mind that this is not just an issue for users of Ubuntu and a one-off fix is not what is needed. I'm on macOS and also still seeing AM/PM because my system's language is set to en-US (with a 24-hour clock). Signal needs to either find a technical way to detect the system's time format (time ≠ language!) and honor it or provide an option for a 24-hour clock so users can at least set it themselves.

[alametti]

@jamiebuilds-signal I changed my numbers, currency and time format setting in the Ubuntu/Gnome graphical system preferences menu as follows:

This changed my locale variables as follows:

$ locale
LANG=en_CA.UTF-8
LANGUAGE=en_CA:en
LC_CTYPE="en_CA.UTF-8"
LC_NUMERIC=fr_CA.UTF-8
LC_TIME=fr_CA.UTF-8
LC_COLLATE="en_CA.UTF-8"
LC_MONETARY=fr_CA.UTF-8
LC_MESSAGES="en_CA.UTF-8"
LC_PAPER=fr_CA.UTF-8
LC_NAME=fr_CA.UTF-8
LC_ADDRESS=fr_CA.UTF-8
LC_TELEPHONE=fr_CA.UTF-8
LC_MEASUREMENT=fr_CA.UTF-8
LC_IDENTIFICATION=fr_CA.UTF-8
LC_ALL=

However, this did not change the behaviour in signal-desktop:

$ signal-desktop --debug
Set Windows Application User Model ID (AUMID) { appUserModelId: 'org.whispersystems.signal-desktop' }
#...
{"level":30,"time":"2023-08-07T21:00:59.192Z","msg":"app.ready: preferred system locales: en-CA, en"}
{"level":30,"time":"2023-08-07T21:00:59.192Z","msg":"locale: Supported locales: af-ZA, ar, az-AZ, bg-BG, bn-BD, bs-BA, ca, cs, da, de, el, en, es, et-EE, eu, fa-IR, fi, fr, ga-IE, gl-ES, gu-IN, he, hi-IN, hr-HR, hu, id, it, ja, ka-GE, kk-KZ, km-KH, kn-IN, ko, ky-KG, lt-LT, lv-LV, mk-MK, ml-IN, mr-IN, ms, my, nb, nl, pa-IN, pl, pt-BR, pt-PT, ro-RO, ru, sk-SK, sl-SI, sq-AL, sr, sv, sw, ta-IN, te-IN, th, tl-PH, tr, ug, uk-UA, ur, vi, yue, zh-CN, zh-HK, zh-Hant"}
{"level":30,"time":"2023-08-07T21:00:59.192Z","msg":"locale: Preferred locales:  en-CA, en"}
{"level":30,"time":"2023-08-07T21:00:59.193Z","msg":"locale: Matched locale: en"}
#...

The current behaviour does indeed seem to be to force use of a 12-hour time format if the language is set to en or en_* (I tried with en_AU as well)

[jamiebuilds-signal]

@alametti Ah, thanks for that, it looks like it's accessible with gsettings get org.gnome.desktop.interface clock-format (GNOME specific). This complicates things further though if each Linux flavor has its own method for the same setting.

[jamiebuilds-signal]

@Shnub Please check that you are on the latest version of Signal. The latest version includes changes to respect macOS's 12/24-hour cycle setting.

[Shnub]

I'm on 6.27.1, which appears to be the latest, and I'm still seeing AM/PM.

[jamiebuilds-signal]

@Shnub Oh apologies, it's still in the 6.28 beta. (Commit)

[demonbane]

Looks like the beta does indeed fix it on MacOS at least. 6.27.1 on the left, 6.28.0-beta.2 on the right.

[jamiebuilds-signal]

@demonbane Sweet, thank you for verifying

Looks like the beta does indeed fix it on MacOS at least.

For now this is on macOS only. Each operating system works a bit different and there aren't exactly great libraries for this. Windows is going to be interesting to solve because it allows for very extensive customization. Hopefully with Linux respecting LC_TIME will be enough for the majority of users. And past that we're looking at what in-app settings we should expose here

[norstbox]

@jamiebuilds-signal

Windows is going to be interesting to solve because it allows for very extensive customization.

It would be ideal to get exactly the 12/24-hour clock preference, like on a Mac. But what do you think about switching to the locale to determine the clock format, https://github.com/signalapp/Signal-Desktop/issues/4252#issuecomment-1624556774? It's not a perfect solution, but seems more appropriate than infer from the system language.

[mathieu-lemay]

@jamiebuilds-signal

Have you considered adding an explicit option for this? It could work the same way than the Theme option, with 3 options being: System/Auto, 12h and 24h. This way if the auto detection is not working properly, at least the users can override it.

[tmanaud]

On Mint signal-desktop 6.27.1 from PPA with locale:

LANG=en_US.UTF-8 LANGUAGE=en_US LC_CTYPE="en_US.UTF-8" LC_NUMERIC=fr_FR.UTF-8 LC_TIME=fr_FR.UTF-8 LC_COLLATE="en_US.UTF-8" LC_MONETARY=fr_FR.UTF-8 LC_MESSAGES="en_US.UTF-8" LC_PAPER=fr_FR.UTF-8 LC_NAME=fr_FR.UTF-8 LC_ADDRESS=fr_FR.UTF-8 LC_TELEPHONE=fr_FR.UTF-8 LC_MEASUREMENT=fr_FR.UTF-8 LC_IDENTIFICATION=fr_FR.UTF-8 LC_ALL=

Does show AM/PM US time format

[Shnub]

@jamiebuilds-signal

I just installed the public 6.28.0 and times are still in AM/PM:

These are my system settings:

The debug log shows this after launching 6.28.0:

INFO  2023-08-09T12:13:28.792Z app.ready: hour cycle preference: UnknownPreference
INFO  2023-08-09T12:13:28.792Z app.ready: preferred system locales: en-US
INFO  2023-08-09T12:13:28.793Z locale: Supported locales: af-ZA, ar, az-AZ, bg-BG, bn-BD, bs-BA, ca, cs, da, de, el, en, es, et-EE, eu, fa-IR, fi, fr, ga-IE, gl-ES, gu-IN, he, hi-IN, hr-HR, hu, id, it, ja, ka-GE, kk-KZ, km-KH, kn-IN, ko, ky-KG, lt-LT, lv-LV, mk-MK, ml-IN, mr-IN, ms, my, nb, nl, pa-IN, pl, pt-BR, pt-PT, ro-RO, ru, sk-SK, sl-SI, sq-AL, sr, sv, sw, ta-IN, te-IN, th, tl-PH, tr, ug, uk-UA, ur, vi, yue, zh-CN, zh-HK, zh-Hant
INFO  2023-08-09T12:13:28.793Z locale: Preferred locales:  en-US
INFO  2023-08-09T12:13:28.795Z locale: Matched locale: en

Apparently the detection of the system setting isn't working for me.

I'm on macOS 12.6.7