Apache OpenOffice (AOO) Bugzilla – Issue 98616
user should be able to specify input calender in cell format
Last modified: 2013-08-07 15:12:27 UTC
Hello, There is Problems in Calc dealing with the Hijri date. for example if I entered 1/1/1430 I'll get 1/1/30. that is right if I entered Gregorian date (even thought I don't like this format :) ) but I entered Hijri date, so I go right click >> format cell... >> language: Arabic >> format:24/9/1420 >> I get this :6/04/833 it looks like this feature works like date converter from Gregorian to Hijri while it shouldn't. on an Arabic local: if I enter: 1/1/1430 it will show like 6/04/833 1/1/2009 it will show 5/01/1430 (١٤٣٠/٠١/٥) Which means that the date is forced to be entered in Greg I've talked on #dev.openoffice.org and was advised to use ' before the date. well this is not a solution because it will make the date into a string which can't be manipulated as a date formatting the cell should contain the expected input date regards :)
It is surely desired to be able to enter dates in different calendars, not just the default calendar of a locale, which for Arabic locales happens to be the Gregorian calendar as well. Just to illustrate the reasoning why we currently do not switch calendars during input and a solution would be non-trivial, taken from a comment in svtools/source/numbers/zforfind method ImpSvNumberInputScan::GetDateRef() We are currently not able to fully support a switch to another calendar during input for the following reasons: 1. We do have a problem if both (locale's default and format's) calendars define the same YMD order and use the same date separator, there is no way to distinguish between them if the input results in valid calendar input for both calendars. How to solve? Would NfEvalDateFormat be sufficient? Should it always be set to NF_EVALDATEFORMAT_FORMAT_INTL and thus the format's calendar be preferred? This could be confusing if a Calc cell was formatted different to the locale's default and has no content yet, then the user has no clue about the format or calendar being set. 2. In Calc cell edit mode a date is always displayed and edited using the default edit format of the default calendar (normally being Gregorian). If input was ambiguous due to issue #1 we'd need a mechanism to tell that a date was edited and not newly entered. Not feasible. Otherwise we'd need a mechanism to use a specific edit format with a specific calendar according to the format set. 3. For some calendars like Japanese Gengou we'd need era input, which isn't implemented at all. Though this is a rare and special case, forcing a calendar dependent edit format as suggested in item #2 might require era input, if it shouldn't result in a fallback to Gregorian calendar. 4. Last and least: the GetMonth() method currently only matches month names of the default calendar. Alternating month names of the actual format's calendar would have to be implemented. No problem.
we should give the one who write the document away to set the expected input calendar and save that this way even if both Gregorian and Hijri have the same DD-MM-YYYY format for user level one can go to cell format and specify both input and display formats this solves 1. and 2. point 3. means that more effort is needed