GNOME Bugzilla – Bug 608474
empathy chat timestamps not in gnome-specified format
Last modified: 2018-05-22 14:00:07 UTC
For long running IM conversations, empathy helpfully displays a timestamp every so often. unfortunately, does not respect the configured-elsewhere-in-gnome/locale date/time format, and displays, for example "16:05" instead of "4:05 PM".
work fine for me in empathy 2.29.6 If I config for "16:05" for gnome-locale config, empathy show "16:05"
Joe: Which version are you using? Could you try with 2.29.6 please?
I have only tried 2.28.1.1, and it doesn't work. E.g., "env LC_TIME=en_US.UTF-8 empathy" makes empathy show "16:05" instead of "04:05:00 PM" (whereas "env LC_TIME=en_US.UTF-8 date -d '16:05' +%X" displays "04:05:00 PM" as it should).
in empathy 2.29.91, i see: - Wednesday February 24 2010, 13:28 - (instead of 1:28PM)
looks like libempathy-gtk/empathy-chat-text-view.c does: tmp = empathy_time_to_string_local (timestamp, EMPATHY_TIME_FORMAT_DISPLAY_SHORT); where libempathy/empathy-time.h defines: #define EMPATHY_TIME_FORMAT_DISPLAY_SHORT "%H:%M" would changing chat-text-view.c to: tmp = empathy_time_to_string_local (timestamp, _(EMPATHY_TIME_FORMAT_DISPLAY_SHORT)); work? ... not sure how these things are usually localized, and just randomly guessing ... .... (also, to clarify, I'm expecting 12-hour (1:28PM) time format with en_US.UTF-8 locale.)
this bug is still reproduce?
yes
what is version? -> empathy
2.30.0
Could you try with 2.31.92 (or the upcoming 2.32.0) plese? We change a few things in this code to improve localisation.
I am using 2.32.0 and I get inconsistent timestamp formats. Here's an example: madLyfe has joined the room 16:21 ZykoticK9_ 10/11/2010 04:20:59 PM !puregnome | Cuervo Ignoring the fact that the two events seem misordered -- I cut-and-pasted them as they arrived -- I would like to make the 'from a message' timestamp format the same as the 'join/quit' timestamp. How do I do that?
*** Bug 657356 has been marked as a duplicate of this bug. ***
Created attachment 205636 [details] [review] empathy-time: port to TP coding style
Created attachment 205637 [details] [review] Use org.gnome.system.locale.region when displaying dates
Created attachment 205638 [details] [review] stop translating date/time formats We don't have to any more as we respect GNOME's region setting.
If that's how it is supposed to be used, then +1
I may be missing something here, but how is %H:%M supposed to change to %I.%M?
Comment on attachment 205636 [details] [review] empathy-time: port to TP coding style Attachment 205636 [details] pushed as 11de29c - empathy-time: port to TP coding style
Review of attachment 205637 [details] [review]: That's not the right approach. gnome-settings-daemon set this variable for us, we just have to make sure all our formats are localized.
(In reply to comment #17) > I may be missing something here, but how is %H:%M supposed to change to %I.%M? You're right, the right fix is to use a localized string. As there is no equivalent (bug #668323) we'll have to use %X for now.
Created attachment 205689 [details] [review] Use a localized format when displaying times Unfortunatelly there is no localized format displaying only the hour and minutes (bug #668323) so we'll have to use %X for now which also display the seconds. EMPATHY_DATE_FORMAT_DISPLAY_SHORT was already localized so this one is fine. That also means we don't have to translate those formats any more as we'll just rely on the system env.
Looks better to me :) +1
Created attachment 205690 [details] test script For the record, here is the small script I wrote to test formats.
Attachment 205689 [details] pushed as 7d6b479 - Use a localized format when displaying times
So the format will change when I use the 12/24 hour switch in the Date and Time settings panel, right?
(In reply to comment #25) > So the format will change when I use the 12/24 hour switch in the Date and Time > settings panel, right? We rely on the system localization of the "%X" format which depends of the local settings (like LC_TIME). Those locales can be configured using gnome-control-center's language panel. Not sure if that's the same as the 12/24 setting.
That isn't the same iirc. It needs to follow the 12/24 setting.
Why do we have 2 settings for this? Isn't the point of the region panel to configure exactly that?
Jon: I don't mind you re-opening the bug but please clarifiy the different settings as well. We have at least 2 settings here: "org.gnome.system.locale region" which is set in the "Region and Language / Formats" panel. gnome-session reads this setting and set LC_TIME accordingly. Once set, localized strftime formats are automatically localized. "org.gnome.desktop.interface clock-format" which is set in the "Date and Time" panel and seems specific to gnome-shell's clock. From my understanding, the former is more general and should be the one app should rely on. Actually, one may claim that the latter should be implicit and derivated from the former.
Sorry, I have no idea about the dconf settings. From the user's perspective the times used on the system should follow the 12/24 switch in the Date and Time settings panel. I imagine the locale would provide the default setting for the 12/24 switch and the user would be able to change it as needed.
The point is that the preference should override the locale-provided data. You will display the time (or more likely, date) in a particular language. The user wants to be able to choose whether to use 12 or 24 hour format. That's independent of the locale. It's also very important for some locales where the usage is very dependent on the person's role, or upbringing.
(In reply to comment #30) > Sorry, I have no idea about the dconf settings. From the user's perspective the > times used on the system should follow the 12/24 switch in the Date and Time > settings panel. > > I imagine the locale would provide the default setting for the 12/24 switch and > the user would be able to change it as needed. So yeah, the current situation is pretty confusing; I opened bug #671870
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/empathy/issues/179.