Issue 98616 - user should be able to specify input calender in cell format
Summary: user should be able to specify input calender in cell format
Alias: None
Product: Calc
Classification: Application
Component: formatting (show other issues)
Version: OOo 3.0
Hardware: All All
: P3 Trivial with 6 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2009-01-29 16:21 UTC by uaa
Modified: 2013-08-07 15:12 UTC (History)
2 users (show)

See Also:
Issue Type: FEATURE
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description uaa 2009-01-29 16:21:08 UTC

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 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 :)
Comment 1 ooo 2009-01-29 17:12:13 UTC
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.
Comment 2 alsadi 2009-01-29 17:32:30 UTC
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