Apache OpenOffice (AOO) Bugzilla – Issue 102356
Calc assumes all date value input/output to be in Buddhist era when use Thai locale
Last modified: 2013-08-07 15:15:15 UTC
Symptom:- Before OOo 3.1, regardless of user's locale setting, date value input in Calc are always treat as AD. Date value are also always display as AD unless user specify [~buddist] in the cell's number format. In OOo 3.1 Calc, the behavior have been changed (unintentionally, I guess). Tested on Windows XP/Vista and Ubuntu 8.04. If the user's locale (Regional and Language Options on Windows or LANG on Linux) is not Thai. The behavior is the same as before. But if the user's locale is Thai. - date value inputs are treated as if they were in Buddhist era and convert to AD before storing internally. Looking at the content.xml in the ODS confirm that. - when date value have to be displayed, the year are converted from AD to Buddhist era This is regardless of OOo internal locale setting and the cell's locale. The behavior depends on the OS user's locale only. Problem:- Thai people and documents use both AD and Buddhist era in dates so users may input both, in 2-digits and 4-digits forms. Before, we teach users to always input dates in Calc in AD so the date calculation can be performed. Even more problematic is that Thai users may or may not set the user's locale to Thai. So they'll see different behavior, and worse, different display of the same date on different machines. This problem is very serious and render Calc 3.1 unusable in Thai. Test Case:- - Set the user's locale to Thai. On Windows, set the Rigional and Language Options > Formats > Current format to Thai (Thailand). On Linux set the LANG variable to th_TH. - start OOo 3.1 Calc, create an empty sheet - input the following date in separate cells :- 1/12/2552 1/12/52 (will be incorrectly 1952 not 2552) 1/12/2009 1/12/09 (well be 2009) - format all cell using DD/MM/YYYY to see all digits of the years - you can also try set all cell to use Language=Thai - save as ODS file - set the user's locale to English. On Window, set the Rigional and Language Options > Formats > Current format to English (United States). On Linux set the LANG variable to en_US. - open the ODS file, you will see the following 01/12/2009 01/12/1409 01/12/1466 01/12/1466 If you still not believe your eyes, you can change the user's locale back to Thai and restart Calc and reopen the file, you'll get the dates as you entered them. ODF Segment:- <table:table table:name="Sheet1" table:style-name="ta1" table:print="false"> <table:table-column table:style-name="co1" table:default-cell-style-name="ce1"/> <table:table-row table:style-name="ro1"> <table:table-cell office:value-type="date" office:date-value="2009-12-01"> <text:p>01/12/2009</text:p> </table:table-cell> </table:table-row> <table:table-row table:style-name="ro1"> <table:table-cell office:value-type="date" office:date-value="1409-12-10"> <text:p>01/12/1409</text:p> </table:table-cell> </table:table-row> <table:table-row table:style-name="ro1"> <table:table-cell office:value-type="date" office:date-value="1466-12-10"> <text:p>01/12/1466</text:p> </table:table-cell> </table:table-row> <table:table-row table:style-name="ro1"> <table:table-cell office:value-type="date" office:date-value="1466-12-10"> <text:p>01/12/1466</text:p> </table:table-cell> </table:table-row> </table:table>
Created attachment 62636 [details] dates entered in Calc 3.1 in Thai locale
Created attachment 62637 [details] screenshot when entering the dates in Thai locale
Created attachment 62638 [details] screenshot when load the same sheet in English locale
Grabbing issue.
In cws thaical311: revision 274181 i18npool/source/calendar/calendar_gregorian.cxx Seems this went in with the upgrade to ICU 4.0 done for OOo3.1; apparently that has a bug and uses the Buddhist calendar not only with th_TH_TRADITIONAL, but already with th_TH. Anyway, in the corresponding code we always want a Gregorian calendar, forcing that now.
Reassigning to QA for verification. To test use LC_ALL=th_TH scalc
Thanks :)
sba->samphan: Thx for looking at this also. On what platform did you check? I verified in CWS thaical311 on WinXP with the settings seen in thescreenshots. I will look on Linux by tomorrow unless someone else is faster again and comments here :-) AutoTests look good so far, I expect to approve this CWS by tomorrow.
Verified in CWS thaical311 on Linux, too.
See also: http://extensions.services.openoffice.org/project/fixthaidate and http://www.osdev.co.th/sites/default/files/download/send/FixThaiDate_Document.pdf
Note to prevent confusion: that extension does not fix the symptom of this issue. Instead, it addresses a different problem: many users are used to the Buddhist calendar and enter dates with the Buddhist year, but the calendar used for input is the Gregorian calendar. You do not notice the difference immediately because only the year differs by 543. The extension changes the date value of a cell by subtracting 543 years. Ironically, with OOo3.1 in a th_TH locale a Buddhist date input would be interpreted correctly, also displayed per default, only if explicitly displayed in a [~buddhist] format would be wrong. The date stored though would also be in Buddhist calendar, and thus wrong if the document was loaded in a different locale. Users working only in a th_TH locale and only with documents created in OOo3.1 unfortunately won't even notice this bug :-(
Hello samphan, *, I have tested your attached *ods with "LC_ALL=th_TH $PATH_TO_CALC" and can confirm, that it is not fixed with OOO310m18 under Debian SID AMD64 ... :( @samphan: Which architecture are you using: 32bit or 64bit? And could you test it again under Win XP, please? TIA Thomas.
@thackert: The attached document already has the erroneous date values stored. The fix is that new dates entered are again interpreted in the Gregorian calendar.
Hello samphan, *, ah, O.K. As I am not able to write in Thai, I have tested it with our attached file, sorry ... :( But does your entry mean, that this issue is fixed? If so: Could you please close it as "Close fixed"? TIA Thomas.
This issue is closed automatically. It is in state 'verified/fixed' since 2 releases (OOo 3.1.1 and OOo 3.2). The policy [1] indicates that such older issues should be closed. If this issue still occur in a current build (OOo 3.2.1 or >DEV300m80) please reopen the issue and set the target accordingly. [1] : http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues