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

[jamiebuilds-signal]

@Shnub Weird suggestion I know, but would you mind toggling the "Time format: 24-Hour Time" checkbox in System Preferences > Language & Region off and on again and restarting the Signal app?

I've noticed a couple of times that when the setting is changed automatically from other language settings that it sometimes doesn't actually update in your defaults

[Shnub]

I did so, but no change, and still:

INFO 2023-08-09T17:13:01.081Z app.ready: hour cycle preference: UnknownPreference

Edit:

What's the defaults domain/setting for time format? I searched through the whole defaults read output but couldn't find anything.

[jamiebuilds-signal]

The two defaults are AppleICUForce24HourTime and AppleICUForce12HourTime

[Shnub]

I think I know what's going on: as per its name, Apple seems to only use this setting in defaults if it is contrary to what is usually associated with the selected region. While my language is set to English (US), my region is set to Germany, where a 24-hour clock is used. If I deselect 24-Hour Time in System Preferences, I immediately see AppleICUForce12HourTime = 1 in defaults and Signal picks that up:

INFO 2023-08-09T21:40:35.264Z app.ready: hour cycle preference: Prefer12

However, if I switch back to the 24-hour clock, instead of AppleICUForce24HourTime appearing in defaults, there is just no preference for time format stored, and Signal is back to having no clue:

INFO 2023-08-09T21:49:39.561Z app.ready: hour cycle preference: UnknownPreference

Conversely, if I change my region to United States and use a 12-hour clock, there is again no preference in defaults for Signal to see. But if I now switch to the 24-hour clock, AppleICUForce24HourTime = 1appears in defaults and finally Signal can pick it up...

INFO 2023-08-09T22:00:29.787Z app.ready: hour cycle preference: Prefer24

... and display the right time format:

So it appears the 'AppleICUForceXXHourTime' preference is not a reliable indicator of the user-chosen time format; rather it is only used when a time format unusual for the selected region is used.

... and so unless this is a macOS bug (unlikely) or the behavior changed with macOS 13 or 14 (someone with one of those versions installed please check), we're back to this not being a general solution and an option within Signal being needed to solve the issue.

[alametti]

@Shnub This seems to just be another outcome of the choice to base Signal's time format on the user's language rather than the time format locale. Presumably, the cross-platform fix is to use the user's time format locale by default, and perhaps also look for additional preferences (like gsettings get org.gnome.desktop.interface clock-format on GNOME-based distros or AppleICUForce24HourTime on OS X).

The ideal implementation, in my opinion, would be to allow the user to select between the detected system settings (auto), as well as to force 12/24h if that somehow doesn't work or isn't desired.

[Shnub]

This seems to just be another outcome of the choice to base Signal's time format on the user's language rather than the time format locale.

Agreed. Preferred clock format cannot be inferred from preferred language.

Presumably, the cross-platform fix is to use the user's time format locale by default

Yes, though I believe the problem in case of macOS is that there is no time format locale, or at least not one accessible to Signal/Electron or visible in defaults. Apparently macOS only stores anything about clock type in defaults when the used clock is contrary to the used region (as per my previous comment).

There is a preference available in defaults that seems to reflect the region selected in System Preferences, called AppleLocale, which in my case is given as "en_DE". This would allow a much more reliable automatic setting of Signal's time format than language(s) since few countries (if any outside of US...?) have more than one clock in widespread use. But I don't know if Signal can access this. Right now Signal gives me...

preferred system locales: en-US

... which definitely is my selected language rather than my selected region.

The ideal implementation, in my opinion, would be to allow the user to select between the detected system settings (auto), as well as to force 12/24h if that somehow doesn't work or isn't desired.

Agreed as well, especially since it would solve the problem for all OSes. While automatic detection is always preferable, it's obviously not possible (let alone reliably) in this case, and I don't have to repeat how long this whole things has been an issue for Signal Desktop.

[jamiebuilds-signal]

While my language is set to English (US), my region is set to Germany, where a 24-hour clock is used.

@Shnub This was really helpful, we actually need to base the time preference on AppleLocale rather than AppleLanguages. This is why we were not receiving AppleICUForce12/24HourTime values for you

AppleLanguages = [ 'en-US' ] = [ 'h12' ]
AppleLocale = 'en_DE' = [ 'h23' ]
AppleICUForce12HourTime = false
AppleICUForce24HourTime = false

[ghost]

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: electron/electron#13023 (comment)

yeah, we all know that Electron is shit, though workaround is to add option with format to Signal settings ))

[briped]

While I don't see this as a solution, I do see it as a work around until Signal adds an GUI option for the same. Edit the ephemeral.json file located in your %USERPROFILE%\AppData\Roaming\Signal folder.

Change:

"localeOverride": null

to your preferred locale. In my case it would be en-DK (for English language and Danish formatting):

"localeOverride": "en-DK"

Afterwards Signal shows the timestamp as I expect them to be shown.

I have not tested this approach on my Ubuntu laptop, but I would imagine a similar approach is possible on there as well.

[PeteSapai]

Change: "localeOverride": null to "localeOverride": "en-DK"

There was no "localeOverride": null, so I just added it. But alas, it didn't work. I tried en-DK, en-SE, en-UK, but I still have the AMs and PMs.

If only there was a simple solution, like adding an option to set the time format manually...

[Shnub]

@briped That actually works for me (for now). Of course not a solution but I'll take the workaround over AM/PM or being forced to switch to another language. Thank you!

@PeteSapai Did you make sure to include the quotes around en-DK etc.? In my first attempt I forgot them and Signal just rebuilt the entire file upon launching, resetting to the variable to null.

[PeteSapai]

Did you make sure to include the quotes around en-DK etc.? In my first attempt I forgot them and Signal just rebuilt the entire file upon launching, resetting to the variable to null.

I did:

  "theme-setting": "system",
  "localeOverride": "en-SE",
  "spell-check": false,

But as I mentioned, I don't have the "localeOverride": null in there by default. If I add it incorrectly (e.g. by omitting the comma) the file is rebuilt excluding the localoverride part.

And while I was typing that I thought: "maybe it's a version thing..." Then I noticed that I was running a slightly older version (Sep 29) because the auto-update wasn't auto-updating. After installing the latest version and modifying ephemeral.json I now finally have the 24h format!

[alametti]

I have not tested this approach on my Ubuntu laptop, but I would imagine a similar approach is possible on there as well.

This solution works on Ubuntu 23.04 with signal-desktop from apt (version 6.41.0).

I modified ~/.config/Signal/ephemeral.json to:

    "localeOverride": "en-GB"

...and:

[felixvanoost]

I have not tested this approach on my Ubuntu laptop, but I would imagine a similar approach is possible on there as well.

This solution works on Ubuntu 23.04 with signal-desktop from apt (version 6.41.0).

I modified ~/.config/Signal/ephemeral.json to:

  "localeOverride": "en-GB"

...and:

This worked for me on Ubuntu 22.04 as well.

[maartenhunink]

I think my experience confirms what @Shnub is describing.

My system settings on osx were:

Language: English Region: Dutch Time Format: 24h

But this still gave me the 12h format.

When I changed the Region to UK, which triggered the system to change the language to EN_UK, while keeping the time format to 24h, it then also changed Signal to the 24h format.

[rloutrel]

I have not tested this approach on my Ubuntu laptop, but I would imagine a similar approach is possible on there as well.

This solution works on Ubuntu 23.04 with signal-desktop from apt (version 6.41.0).

I modified ~/.config/Signal/ephemeral.json to:

  "localeOverride": "en-GB"

...and:

For snap versions, the settings file is modifiable as follow:

/!\ The setting file is overridden by the application as it shuts down, with the value as it started (at least for this parameter). Therefore, do the modifications, once it is shut off /!\

vim current/.config/Signal/ephemeral.json
# or nano, gedit, kate or whatever your editor is

[Sofviic]

Why is there still not an option to override its assumed defaults yet?