To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=98616
User er changed the following:
What |Old value |New value
================================================================================
CC|'' |'er'
--------------------------------------------------------------------------------
Ever confirmed| |1
--------------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
--------------------------------------------------------------------------------
Issue type|DEFECT |FEATURE
--------------------------------------------------------------------------------
Platform|PC |All
--------------------------------------------------------------------------------
Target milestone|--- |OOo Later
--------------------------------------------------------------------------------
------- Additional comments from [email protected] Thu Jan 29 17:12:13 +0000
2009 -------
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.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
