GNOME Bugzilla – Bug 205137
Configurable date formats in components
Last modified: 2010-04-02 11:37:50 UTC
When selecting from the pop-up calender for a contact's birthday or anniversary, it would be preferable to have an option of how to display the date. At present only the American MM/DD/YYYY format is available while many would like the European DD/MM/YYYY style. Furthermore when you type in a date this should link to your chosen format rather than defaulting at American.
It would be good to have the ISO date format (CCYY_MM-DD) (if this was the default it would avoid confusion) Additional suggestion to tir date format in with time locale
gettext is used to determine the format to use for display, so it is localized. Or is it not being localized correctly? (Changing to address book component)
*** bug 211198 has been marked as a duplicate of this bug. ***
Fixing this bug is a 1.1 goal.
This is an EDateEdit issue, so reassigning back to calendar.
Because of the decision to remap 1.1->1.2 and 1.2->1.4, I'm going to be moving a large number of bugs around in the bugzilla. You can just search on 'body contains' 'Because of the decision to remap' and mark all as read. Please direct all questions about this change to evolution@ximian.com, not the bug. Luis
This is probably a bug in the po files. Maybe we should check through all of them to make sure they are doing sane things with the strftime formats.
*** bug 220775 has been marked as a duplicate of this bug. ***
*** bug 220386 has been marked as a duplicate of this bug. ***
*** bug 213524 has been marked as a duplicate of this bug. ***
*** bug 215915 has been marked as a duplicate of this bug. ***
*** bug 215054 has been marked as a duplicate of this bug. ***
*** bug 218206 has been marked as a duplicate of this bug. ***
*** bug 210685 has been marked as a duplicate of this bug. ***
*** bug 204501 has been marked as a duplicate of this bug. ***
I'll try to be a little more specific: People wants a more flexible, localized, date / time display in different places: - Birthdate (Contacts) bug 205137 - Sent and received (Mailer) bug 213524, bug 215915, bug 204501 - Tasks, bug 220775, bug 211198 - General (Shell) bug 220386, bug 215054 - Calendar bug 218206, bug 210685
bug 204501 is not about the Mailer "Sent" and "Recieved" columns, it's about the date format displayed in the default mail header in the mail view.
*** bug 227647 has been marked as a duplicate of this bug. ***
*** bug 230742 has been marked as a duplicate of this bug. ***
*** bug 231851 has been marked as a duplicate of this bug. ***
Futuring since 1.4 is just porting. This is one of the most requested wishlists. Does anyone mind to retarget this?
*** bug 237897 has been marked as a duplicate of this bug. ***
Is a fix for this still in the works? The randomly varying date formats in the mailer are driving me nuts!! :-)
*** bug 256689 has been marked as a duplicate of this bug. ***
*** bug 259709 has been marked as a duplicate of this bug. ***
*** bug 270607 has been marked as a duplicate of this bug. ***
This bug has been present since 2001 now. Using international date time standards should be a must for a Calendar component.
This one is getting to me as well. Severity: enhancement Target: Future Excuse me? This isn't merely an 'enhancement', it's necessary! Why hasn't this been fixed yet? Sorry for being rude.
As I stated the last time: International date/time standards are there for a reason. A Calendar is expected to follow them. This bug has been around for more than 4 years now. http://www.iso.org/iso/en/prods-services/popstds/datesandtime.html http://www.cl.cam.ac.uk/~mgk25/iso-time.html Suitable Severitylevel: "Major Major loss of functionality- menu item broken, data output extremely incorrect, or otherwise difficult/useless to use."
Are there any Europeans involved with Evolution developement? It's shame that this kind of basic things are still broken in core GNOME application. I agree that severity should be major.
Forget Europeans. Try are there any non-American (and more spefically non-North American) Evolution developers. I'm astounded that Evolution could have been through two major number releases and a handful of minor number releases and still not handing non-US date formats. Surely GTK+ has a widget for handling such things, and if not, then why not. This is quite embarrassing for an application that handles calendars and task management can't do dates properly.
That kind of attitude (of the Evolution developers) doesn't help GNOME to spread in other parts of the world. KDE has had excellent i18n for years and maybe that is one of the many reasons why it's so popular in Europe. Of course, I know that there are almost one thousand Evolution bugs to fix in Bugzilla and the developers have been very busy and hard-working with them. Thanks for them for that! However, I wish they wouldn't ignore the basic things.
I can't find any other explanation for this bug being still open than that the Evolution developers don't understand what it is about. The bug title as well as the initial descriptions don't match very well with the latter comments and the duplicate bugs. I propose that title should be changed to something like: "Components don't follow the system date settings". Also, this should be *bug*, not a feature postponed to distant future.
As there is no way of telling from say "06/08/2006" if this means August 6th or June 8th, I have to remind myself every time I look at a Task that my project start date is in the, to us foreigners, counter-intuitive US mm/dd/ccyy format. If Evolution can internationalise language and time, surely it can manage this rather obvious tweak. Sorting tasks in order of selected field would be nice too, but lets get the basics right first.
I think there should be an option to set the date format for other than the Locale. This can be important when there is a conversion or difference between the Locale settings and the prefered format. I have yet to find a simple way to convert my Linux box to a custom setting for date/time etc. The locale of choice doesn't have the date format that our organization uses by default. Of course there are times that we have users that want to use their prefered date format. I want to be able to choose ISO date format even though my Locale is set for Canada. I also don't like the idea that Evolution decides that I want just the time displayed or Yesterday or Today. I want YYYY-MM-DD-HH:MM for everything. I find this very distracting and annoying to the point of just closing Evolution when I am not reading.
This bug is only six years old now. :)
I am astonished to find that this bug, and it is a B*U*G not an enhancement, is still unaddressed. Perhaps there should be a new severity category called Embarrassment for highly visible problems that are not actually broken or malfunctioning, just ... well ... embarrassing. As I am now using KDE and Kontact/Kmail this bug is no longer bugging me, so I bid it farewell.
I have given up on Evolution after 10 months of headaches. This date issue is just one of them, the most minor one.
Note that there are two separate issues here: 1) Some (many) people would like a way to specify date formats in Evolution. 2) Local settings are not respected. The first is a popular enhancement request. The second is a bug (see bug 256905, bug 344516, and bug 348929). The end result for the user is of course the same whatever the cause, a calendar that can not display dates correctly.
Actually, I'd add third issue. My biggest complaint is that date formats are inconsistent, making it a pain to figure out when mail was sent or received. When I look at my inbox, I see dates like this: Mon 05:30 PM May 18 2006 Yesterday 07:02 AM Jan 10 11:14 PM 04:19 PM While having a way to specify my preferred date format would be great, I'd settle for simple having a consistent presentation of the date. Sometimes it tells what the month is, sometimes it doesn't. Sometimes we get the year or day of the week, sometimes we don't. Aside from the sheer inconvenience and weirdness of doing it this way, I would think it makes the code unnecessarily complex to have it use random date formats instead of a single consistent one...
Am I the only person with a problem inputting 4-digit years? Like a contacts birthday in 1950, gets treated by calendar as though it were 2050. If the iso debate means we get YYYY-MM-DD, that might fix things.. (though being from the UK I prefer DD-MM-YYYY). Still, I can't see the point of having a birthday slot that can't be used for anyone over 30yrs old. I ask myself, why would the developers provide a birthday slot if you can't use it? Very odd..
Any progress? After seven years, this bug still fails to be addressed, and it IS a serious functionality flaw for anybody who is not accustomed the North American M/D/YY date format. I've stuck with Evolution as a mail client because of its other features, but if I wasn't attached to those, I would have given up on it long ago because of this single bug. I cannot even imagine trying to use the calendar component, if evolution will not allow me to choose how my dates and times are displayed. Ideally, Evolution should respect the date format of my locale, but if that, for whatever reason, cannot be implemented, I need to at least be able to configure it within Evolution. The relative dates in the message listing also need to be an optional feature. Can anybody even attempt a patch? I would if I could, but I'm no developer.
Hello... does anybody care? These are the sort of bugs that keep gnome from becoming scalable. Also, I'm tired of scanning my indox and having to mentally translate every date to something meaningful—the most recent ones are displayed only in terms of weekday, and before that, they are displayed only in terms of date, so I can't relate them in my head. I don't want to come off as non-developer who can only nag, but I don't know how else to fix this. If dates worked in a predictable fashion, then I could understand this bug being filed as an enhancement, but as it stands, I'm sure I'm not the only one who finds this highly annoying, so it really seems to deserve a higher priority, considering the few lines it would take to fix it.
*** Bug 303420 has been marked as a duplicate of this bug. ***
*** Bug 443824 has been marked as a duplicate of this bug. ***
*** Bug 506988 has been marked as a duplicate of this bug. ***
*** Bug 519527 has been marked as a duplicate of this bug. ***
*** Bug 573877 has been marked as a duplicate of this bug. ***
*** Bug 336253 has been marked as a duplicate of this bug. ***
*** Bug 348929 has been marked as a duplicate of this bug. ***
*** Bug 323289 has been marked as a duplicate of this bug. ***
*** Bug 332792 has been marked as a duplicate of this bug. ***
*** Bug 350825 has been marked as a duplicate of this bug. ***
*** Bug 256905 has been marked as a duplicate of this bug. ***
For me the current biggest anoyance (with 2.26) is the 12 hour clock display in the mail folder display. I found the date in this display is formatted in the file widgets/table/e-cell-date.c by the pattern '%l:%M %p'. Changing this pattern wherever it occurs in this file seems to fix the mail display for me - I now get the dates consistently in 24 hour clock. I attach a patch that implements this change. I can only guess someone chose to use the '%l:%M %p' pattern because he wanted to avoid displaying the seconds. Looking at the source code for 2.26 there are 1506 instances of the date pattern '%l:%M %p'. I am now trying out a version of evolution with all of those replaced created by running: grep -Frl '%l:%M %p' . | while read file do sed -e 's/%l:%M %p/%X/g' < $file > /tmp/sed && mv /tmp/sed $file done from the top level of the source tree. Dates seem to be behaving for me now - anyone still have a problem with them?
Created attachment 137817 [details] [review] Change date in mail folder view to respect locale's choice of 12/24hr clock
> Dates seem to be behaving for me now - anyone still have a problem with them? Nothing has changed regarding the inconsistent date formats I complained about in comment 42 above. At least the date formats are still inconsistent in v2.62.2 that I'm using on Fedora 11. I still count at least five different formats being used in the mail folder view. If a "show dates in consistent format" check box option was added somewhere, I'm not seeing it.
*** Bug 580660 has been marked as a duplicate of this bug. ***
*** Bug 582999 has been marked as a duplicate of this bug. ***
Steve, thanks for the patch, though I've something more general.
Created attachment 138062 [details] [review] proposed evo patch for evolution; Adds ability to let user choose his/her own date/time format to show in tables and a date header. I thought to change all localizeable date/time formats in evolution, those for entering too, but after looking around it's quite impossible, not only because of the parsing part is in eds, but also because some parts strictly require some short or long format, where I do not trust users to enter such there. It should be quite easy to extend this for more parts/entering fields, but the only issue I faced is how to configure it in some not-to-get-user-crazy-of-that way. I put there few predefined formats, but users can write there anything acceptable in strftime, with new tag %ad for an abbreviated date (it's the one used in a mailer's table). I thought of writing some sort of help section for it, but I do not have proper tools handy to do that, and killing an xml file is not the best thing, I believe. Thus see 'man strftime' for more information what one can write there.
Created attachment 138063 [details] e-util/e-datetime-format.h
Created attachment 138064 [details] e-util/e-datetime-format.c
Thinking of all the duplicates I marked here recently, it's possible I was wrong with some of them. I'm not sure now.
If it helps, there are at least two distinct bugs here. One is that the date format is not configurable and the other is that date format, configurable or not, is not used consistently. Apparently the date format actually used depends on the relative age of the date and not the users chosen format. So to fix the first bug, there needs to be way for the user to configure the date format. To fix the second bug, there needs to be way for the user to force evolution to actually use the configured date format consistently rather than only after some arbitrary amount of time has passed. In other words if want my dates formatted as YYYY MM DD, HH:MM:SS, I want *ALL* my dates formatted that way, not just dates that are two weeks old or whatever. I don't want it drop the Year if it's one week old or display "Yesterday" instead of my selected format if it's 24 hours old.
(In reply to comment #67) > ... Yes, that does the patch and attached new files above. I'm still talking about showing date and time, not entering it. You can configure this differently for calendar and mail components. There is a configuration for an addressbook too, though it seems it's not used at the moment.
In response to comment 67, yes from the perspective of someone using evolution these are two separate issues. I would class the date format used being neither configurable nor taken from the user's locale as a bug whereas the date format varying depending on the age of the message is a mis-feature, i.e. someone has gone to some trouble to make it work that way but the result is not to everyone's taste. From a technical point of view the two are intimately related. In order to implement the fancy "date format changes with age of message" feature the developer has embedded 6 different date formats into the code none of which respects the user's locale. Having six date formats to configure in a preferences dialogue is probably too many. I'll now try Milan's patch and see how I get on.
The patch seems to work fine for the Etables across components. e-datetime-format.c is not thread-safe. would that be a problem ? I guess since it can be only changed from preferences, it think it should be safe. The mailer and address-book options are provided in wrong tabs. Maybe for mailer the label tab can be named in a generic way for the users to be able to find it faster. But for address-book i don see a place, maybe a new tab ? (not sure). And can we have the default values as abbreviated form (as they are currently) so that it does not surprise users who are used to the abbreviated form. And people who want to use the default locale format can choose from preferences ? This needs to be committed within this week as we have a UI freeze coming up next week.
(In reply to comment #70) > The patch seems to work fine for the Etables across components. > e-datetime-format.c is not thread-safe. would that be a problem ? I guess since > it can be only changed from preferences, it think it should be safe. Sure, as we talked about it on IRC, this is no issue, everything is done on the main thread. > The mailer and address-book options are provided in wrong tabs. Maybe for > mailer the label tab can be named in a generic way for the users to be able to > find it faster. But for address-book i don see a place, maybe a new tab ? (not > sure). This is hard, I've not much idea here. What about putting date/time format options into Headers tab for mailers. It has a bit sense to have it there. The totally different option can be to use a special Component for it, like we have for network preferences, and have all the formats on one place, for different views. Though this is the only "General" option at the moment. > And can we have the default values as abbreviated form (as they are currently) > so that it does not surprise users who are used to the abbreviated form. And > people who want to use the default locale format can choose from preferences ? It's quite simple, pass also 'key' into get_default_format, and if it contains "mail-table" then use "%ad %H:%M" and for the rest "%x %X" (note that the table value for calendar dates wasn't abbreviated).
Created commit b631328 in evo master (2.27.6+) with the above changes done.
Oops, I forgot to mention, the "Autocompletion" configure component is now renamed to "Contacts", not "Addressbook", as we use "Contacts" for such things.
*** Bug 214971 has been marked as a duplicate of this bug. ***
*** Bug 348382 has been marked as a duplicate of this bug. ***