Version: (using KDE KDE 3.0) Installed from: SuSE RPMs I have to use M$ Excel at work but at home I using KDE on my desktop. I found some functions which are quite good and I tested them on my KDE 2.2.1 and on the linuxworldexpo in Frankfurt last week on a demo system in the kde booth with 3.1beta. They are not available in kspread. This is some kind of a wishlist. The German Version of Excel excepts different inputs for dates and converts them to dates in the display of the cell. Following are excepted: 23/2 23/2/02 23.2 23.2.02 those are converted into 23rd of February 2002. This is accepted also in M$ Access as date inputs in date fields. This is something what helps in usability of kspread.
Thank you for your bug report. As far as I can tell, KSpread already uses locale settings of your KDE installation. Therefore, if you set it to Germany for example, then entering "23.2.02" will be treated as 23rd February 2002.
I'm running into this as well. The kspread docs for 1.2.1 (MacOSX 10.2.6, kspread 1.2.1 via fink) indicate: Dates should be entered in your System format, as defined in the K menu Preferences-> Personalisation->Country & Languages dialog box. If, for example, you are using the DD/MM/YYYY form you should enter 30/03/2002 for 30th. March 2002. Leading zeroes can be omitted from the day and month fields and only the last one or two digits of the year need to be entered if the date is in the current century, for example 9/1/2 for 9th January 2002. My K menu (3.1.2) doesn't show this menu; when I go to Kcontrol->regional & accessibility->country/region->time & dates, I change the 'short date' field to YYYY.mM.dD. Then I restart kspread, 2003.8.9 is still not recognized as a date (it's left-justified). The only thing I can get kspread to accept is DD/MM/YYYY. Perhaps I should be changing it someplace else? If I'm doing it right, then I guess it's a bug in kspread; if I'm doing it wrong, let me know and I'll file a bug against the docs in any case.
Halo Carsten, Perhaps the first quick check is to see whether other KDE application already uses this short date setting (as the KDE Control Panel will always affects all KDE application). Also is it possible to go for RC1 version KOffice? KSpread receives significant improvement. However I don't know whether Fink provides non-released package for KOffice. Best regards, Ariya
Hi,The idea, why this should not dependent on the local is that on German Keyboards the ',' is on the numpad and not the for date separation used '.'.The use of the '/' of the numpad gives the possibility to only use the numpad for inputting dates. If you use a US-Keyboard, think about using a date separator which is not on the numpad. This is really slow since you need the second hand to be really fast.regardsCarsten
Request change of summary of this bug to the more descriptive: "entering a date should not be limited to the way specified in the Control Center" Background: http://docs.kde.org/stable/en/koffice/kspread/entering.html contains the following text: Dates should be entered in your "System" format, as defined in the K menu Preferences-> Personalisation -> Country & Languages dialog box. But this is a bad idea, as the original reporter said. The application should be intelligent enough to recognize dates entered in a wide variety of formats. Imagine the following situation: a user sits at somebody else's terminal, perhaps when they's on tour or something, in another country, and opens up KSpread and starts entering a date in a spreadsheet. In one's hurry, one is not likely to notice such a small thing as the alignment of the entry to verify whether it was recognized as a date or not. Later, they try to do some arithmetic with the date or try to create a list by dragging it or something. At *that* point, they find out that the date they entered was not recognized. Now they have to find out the default format and then enter it "correctly". This is clearly a decline in productivity. If the application recognizes the date entered in another format and then immediately converts it to its own default format, then the user notices this change and realizes that they have to interpret the date differently from their usual practice. The two other major spreadsheet apps do this - OOo Calc and Excel. KSpread must be as good. Thanks.
SVN commit 485523 by raphael: CCBUG: 50192 Also allow entering dates in ISO 8601 format, regardless of locale settings. ISO 8601: YYYY-MM-DD including (non-ISO compliant): YYYY/MM/DD I'm reluctant with allowing "more" date formats, especially because Europeans and Americans have a different order for month and day. This basically rules out any other formats than ISO. Please let me know if this satisfies you so we can close the wishlist. Thank you M +27 -0 valueparser.cc --- trunk/koffice/kspread/valueparser.cc #485522:485523 @@ -310,6 +310,33 @@ else fmtType = ShortDate_format; } + if (!valid) + { + //try to use the standard Qt date parsing + tmpDate = QDate::fromString(str); + if (tmpDate.isValid()) + { + valid = true; + } + else + { + tmpDate = QDate::fromString(str,Qt::ISODate); + if (tmpDate.isValid()) + { + valid = true; + } + else + { + QString datestr = str; + tmpDate = QDate::fromString(datestr.replace("/","-"),Qt::ISODate); + if (tmpDate.isValid()) + { + valid = true; + } + } + } + } + if (ok) *ok = valid;
> Also allow entering dates in ISO 8601 format, > regardless of locale settings. > ISO 8601: YYYY-MM-DD > including (non-ISO compliant): YYYY/MM/DD Why YYYY/MM/DD? I do not see any need for it, especially as you reject the idea of providing for all the numerous formats existent. Nobody uses the / with the ISO-ordered date, and even if they do, it will fall under the "more date formats" category you mention below. > I'm reluctant with allowing "more" date formats, > especially because Europeans and Americans have > a different order for month and day. I understand, and 03-04-2005 cannot be determined to be April or March. So telling them to use either their own local system or the ISO system which is supposed to be the international standard is most justified. It will also be a way of training people to use the ISO format which has many other benefits, which are discussed elsewhere on the net. So, if you add support for ISO apart from the local format, I'm satisfied. :) But do just consider my question about the necessity of YYYY/MM/DD.
SVN commit 485628 by raphael: BUG: 50192 Do NOT allow non-ISO compliant date format: YYYY/MM/DD as requested. Now only the ISO format is recognized apart from the local date format. update CHANGES M +2 -1 CHANGES M +2 -19 valueparser.cc --- trunk/koffice/kspread/CHANGES #485627:485628 @@ -8,7 +8,8 @@ - Add a lot of QWhatsThis help to various dialogs - Handbook update for some dialogs - Implement move sheets -- Fix date increment for autofill (#117252) +- Fix date (and time) increment for autofill (#117252) +- Always allow date input in ISO 8601 format, regardless of local settings (#50192) Some important developer visible changes: - Decouple KSpread::Cell and KSpread::Format (association instead of inheritance) --- trunk/koffice/kspread/valueparser.cc #485627:485628 @@ -312,29 +312,12 @@ } if (!valid) { - //try to use the standard Qt date parsing - tmpDate = QDate::fromString(str); + //try to use the standard Qt date parsing, using ISO 8601 format + tmpDate = QDate::fromString(str,Qt::ISODate); if (tmpDate.isValid()) { valid = true; } - else - { - tmpDate = QDate::fromString(str,Qt::ISODate); - if (tmpDate.isValid()) - { - valid = true; - } - else - { - QString datestr = str; - tmpDate = QDate::fromString(datestr.replace("/","-"),Qt::ISODate); - if (tmpDate.isValid()) - { - valid = true; - } - } - } } if (ok)