Version: (using KDE KDE 3.2.3) Installed from: Mandrake RPMs OS: Linux For Birthdays and Anniversaries to work correctly in addressbook, and contact summary. The long date format and the short date format both must have a 4 digit format selected. This makes both formats the same. The short date format should be removed from KDE and all applications as it is a source of continuing problems in date applications and is also redundant as the year format has to be set to four digits making it the same as the long format. Ralph
But the long date (for example "Saturday, the 31th July 2004") is different from the short one (for example "2004-07-31"). So I do not understand your wish. Or is your problem limited to a particular application? (But then why use "kde" as product?) Have a nice day!
My problem is with date formats and kaddressbook. If both date formats are not set to 4 digit year, then the Birthdate, and Anniversary fields are essentially broken and do not work in kaddressbook and kontact. Setting both to a four digit year format, makes both very similar and the short date format unnecceassary/redundant. There is very little difference between the two and removal of the short format would prevent the breaking of the Birthdate, Anniversary fields in Kaddressbook when the long format is 4 digit year (which is neccessary) but the short format is left in 2 digit year format (4 digit year format is also necessary here for the date fields to work). In mind it is just less of a problem if the short format is removed and the function of removeal of the Day of the week left to the application.
So it is a kaddressbook problem... moving the bug then.
No, that is not a bug of KAddressBook or any other application, the realy problem is this 2 digit year format. How shall a computer know whether '33' means 1933 or 2033 when the user doesn't tell him? I got several bug reports over the last month where user complains about 'KAddressBook shows the wrong date' and always these people used the 2 digit format... So please let's set this issue an end by removing this format at all. /me wonders why people didn't learned anything from the y2k bug...
So this is not about the short date format, but about the short year form (%y) I don't really understand what kaddressbook uses this format for, but I don't like removing the possibility to have 01.08.04 in my kicker - just because kaddressbook got a problem there.
On Sun, Aug 01, 2004 at 08:03:37AM -0000, Stephan Kulow wrote: Hi Stephan, > So this is not about the short date format, but about the short year form (%y) Yepp, > I don't really understand what kaddressbook uses this format for, We use it for the input of birthdays/anniversaries as soon as the user has the 'US' locale set, so we can't do anything against it... Storing the format is no problem, but as soon as you want to start some calculations or display the year in a 4 digits presentation the trouble starts... > but I don't like removing the possibility to have 01.08.04 in my kicker - > just because kaddressbook got a problem there. It's not only KAddressBook... you'll see in some years you can't enter 01.08.04 anymore, because it will be interpreted as 01.08.1904 then... Ciao, Tobias
kcmlocale got a difference between short date format and long date format. I still fail to see why the short format should be used in kaddressbook. The default doesn't use %y: klocale.cpp: readConfigEntry("DateFormat", "%A %d %B %Y", m_dateFormat); klocale.cpp: readConfigEntry("DateFormatShort", "%Y-%m-%d", m_dateFormatShort); Beside that: I would love to try, but my kaddressbook always says The resource '_home_coolo_.kde_share_apps_kabc_std.vcf' is locked by application ''. when I try to edit something - fresh from CVS.
To comment #7, I have looked in kdebase/l10n and indeed some countries default to using %y , including some big countries like Australia. (However I do not understand why the short date should go away, as thelong date is quite different.) Have a nice day!
Again I am saying that the short date form of the year being just too digits needs to be removed. The reason being is that applications that uses dates can not tell if the year is 19xx or 20xx. In general most application would default to 19xx, causing most users to report the application as broke, when it is not. The short form two digit year format needs to be removed to prevent this false error. Most users would not think to look for where the date format is specified and change the format to a four digit format for both long and short formats. It is either ensure that all applications force a four digit year format or remove the two digit format. It would be simpler to just remove the two digit format which is problematic now that applications that use dates need to figure out which century it is.
On Monday 06 February 2006 20:06, ralphdewitt@charter.net wrote: (...) > ------- Again I am saying that the short date form of the year being just > too digits needs to be removed. >The reason being is that applications that > uses dates can not tell if the year is 19xx or 20xx. In general most > application would default to 19xx, causing most users to report the > application as broke, when it is not. > The short form two digit year format > needs to be removed to prevent this false error. Wait! Are you telling that we had all that discussion about long and short dates and all what you have wanted is simply to remove the short *year* format, so the %y symbol? > Most users would not think > to look for where the date format is specified and change the format to a > four digit format for both long and short formats. It is either ensure that > all applications force a four digit year format or remove the two digit > format. It would be simpler to just remove the two digit format which is > problematic now that applications that use dates need to figure out which > century it is. Well, as far as I know, some people are used to two digit years, unfortunately. So I still think more or less that it is an application issue. Either the application (or KDE as whole) defines a useful century rule (like the +30 -70 one) or the application should force %Y if it cannot handle %y (not sure if it can be done now in KDE). Have a nice day!
These come from Qt; we can't just remove them.