Version: (using KDE Devel) Installed from: Compiled sources It would be nice to have a separate date format for input of dates. For output it often makes sense to exclude the Year, but for input that's not possible, because it wouldn't yield unambiguous results. In general it might be good, if the date parsing method would be more liberal and not only accept dates exactly fitting the format, but also other unambiguous inputs.
*** Bug 51337 has been marked as a duplicate of this bug. ***
This has not been a problem in the past year. I am guessing I was a duplicate submitter since bugs.kde.org asked If I consider it resolved, but it did not show up under "My Bugs." Feel free to consider it resolved from my end.
Closed based on the submitter's comment.
I doubt that this is fixed. There still is only one date format in kcontrol in KDE 3.2.x and I'm not aware of any changes in the HEAD branch.
This hasn't been changed as of KOrganizer 3.2.1. It would really be nice if this bug were fixed--it doesn't make sense to me that default date display format should affect date input format. I'd like to be able to choose one option for how the date and time is displayed on my small, vertical panel, without losing the ability to enter a year in KOrganizer. Having made a complaint, let me also say that I've used KOrganizer for over a year and have been very pleased with it overall. Thanks for your work in making it a good program. Scott Thatcher
*** Bug 105550 has been marked as a duplicate of this bug. ***
*** Bug 109814 has been marked as a duplicate of this bug. ***
Still applicable in 3.5.6 See http://bugs.debian.org/264041
I think the easiest way to achieve this is to define a new KLocale::DateFormat enum value KLocale::TruncatedDate to only be used with formatDate() which by default would return a date format without the year. It would not be a valid format flag for readDate(). Adding to my TODO list to investigate for 4.5. The big problem I see with this is that one size might not fit all, i.e. the user might want different truncated formats in different contexts (month name vs month number, add weekday name, etc), or the app might not have space to show the users selected truncated format, but I guess that's for the app to then provide a configuration option. From 4.4 we do have a version of formatDate() in KCalendarSystem that directly takes a format string, so apps with special needs can offer their users the chance to choose a different format, although apps are encouraged to stick with the locale formats wherever possible. We just need a decent gui format editor for this, as requiring users to learn format strings is A Bad Thing. readDate() has been a lot more liberal for a while, the base method will accept short and long forms of components regardless of the format string, and there is a convenience version that doesn't take a format but tries all known formats in turn.