Bug 255527 - [BiDi] BIDI3.5: Lack of API for retrieving user's calendar preference from OS
Summary: [BiDi] BIDI3.5: Lack of API for retrieving user's calendar preference from OS
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.5   Edit
Hardware: PC All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Platform UI Triaged CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-11-17 10:52 EST by Tomer Mahlin CLA
Modified: 2019-09-06 15:30 EDT (History)
14 users (show)

See Also:


Attachments
Selecting calendar preference for Korean locale on Windows OS (36.31 KB, image/jpeg)
2008-11-17 10:54 EST, Tomer Mahlin CLA
no flags Details
Selecting calendar preference on MAC OS (43.86 KB, image/jpeg)
2008-11-17 10:55 EST, Tomer Mahlin CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tomer Mahlin CLA 2008-11-17 10:52:13 EST
Background
------------

 On several platforms OS allows end user configure the way dates are formatted. In the context of this defect we review exclusively String representation of dates  (any graphical context such as various date pickers are out of the scope of this discussion). As part of date format configuration user is able to configure calendar preference (see some illustrations for Windows and Mac OS below). 

The problem
------------

  Via ICU4J Eclipse has support for a considerable amount of calendars (12 calendar types). However, right now this support can't be invoked by Eclipse user through any external configuration (i.e. Eclipse command line parameter, OS level configuration). Even those components in Eclipse which do use ICU4J for dates formatting (i.e. PropertiesDialog & Properties view using com.ibm.icu.text.DateFormat.getDateTimeInstance(int, int) for formatting the Last Modified Time property), don't pass calendar information into appropriate date formatting function. This happens for a very simple reason, this information is not available to those components, since user does not have any mechanism to pass this information to Eclipse / ICU4J. As a result in the overwhelming majority of cases only Gregorian calendar is used for date formatting. This is in a sharp contrast to user's experience with other system (OS level) applications which take into account user's calendar preference.
 
The analysis
-------------

 It is possible to retrieve user's calendar preference from OS level using native code. This information can be leveraged by Eclipse components using ICU4J for dates formatting in order to support a great repertoire of calendars. 

Which platforms support user's calendar preference specification ?
-----------------------------------------------------------------
  To the best of my knowledge at least following platforms have support for user calendar preference configuration: OS_WIN32 (13 calendar types) and OS_MACOSX (7 calendar types).

How information about user's calendar preference can be retrieved on OS_WIN32 ?
------------------------------------------------------------------------------
 On this OS user's calendar preference is available via Windows Calendar Identifiers (http://msdn.microsoft.com/en-us/library/ms776338(VS.85).aspx)

1	CAL_GREGORIAN	  			Gregorian (localized)
2	CAL_GREGORIAN_US  			Gregorian (English strings always)
3	CAL_JAPAN	  			Japanese Emperor Era
4	CAL_TAIWAN	  			Taiwan Calendar
5	CAL_KOREA	  			Korean Tangun Era
6	CAL_HIJRI	  			Hijri (Arabic Lunar)
7	CAL_THAI	                        Thai
8	CAL_HEBREW	                        Hebrew (Lunar)
9	CAL_GREGORIAN_ME_FRENCH	                Gregorian Middle East French
10	CAL_GREGORIAN_ARABIC	                Gregorian Arabic
11	CAL_GREGORIAN_XLIT_ENGLISH	        Gregorian transliterated English
12	CAL_GREGORIAN_XLIT_FRENCH	        Gregorian transliterated French
23	CAL_UMALQURA	Windows Vista or later: Um Al Qura (Arabic lunar) calendar

 It can be retrieved using a code similar to the following one:
    LCID = GetSystemDefaultLCID()
    GetUserLocaleInfo(LCID, LOCALE_ICALENDARTYPE)

How information about user's calendar preference can be retrieved on OS_MACOSX ?
------------------------------------------------------------------------------
 On this OS user's calendar preference is available via MAC OS Locale Calendar Identifiers (http://developer.apple.com/documentation/CoreFoundation/Reference/CFLocaleRef/Reference/reference.html#//apple_ref/doc/c_ref/kCFLocaleCalendar)

const CFStringRef kCFGregorianCalendar;
const CFStringRef kCFBuddhistCalendar;
const CFStringRef kCFChineseCalendar;
const CFStringRef kCFHebrewCalendar;
const CFStringRef kCFIslamicCalendar;
const CFStringRef kCFIslamicCivilCalendar;
const CFStringRef kCFJapaneseCalendar;

  It can be retrieved using a code similar to the following one:
       userLocaleRef = CFLocaleCopyCurrent();
       CFLocaleGetValue(userLocaleRef,kCFLocaleCalendarIdentifier)

How calendar information is represented in ICU4J ?
---------------------------------------------------
  In ICU4J calendar information is represented via ICU4J calendar tag values (com.ibm.icu.util.Calendar.java - http://icu-project.org/apiref/icu4j/com/ibm/icu/util/Calendar.html)
   
    private static final int BUDDHIST = 0;
    private static final int CHINESE = 1;
    private static final int COPTIC = 2;
    private static final int ETHIOPIC = 3;
    private static final int GREGORIAN = 4;
    private static final int HEBREW = 5;
    private static final int INDIAN = 6;
    private static final int ISLAMIC = 7;
    private static final int ISLAMIC_CIVIL = 8;
    private static final int JAPANESE = 9;
    private static final int TAIWAN = 10;
    private static final int ETHIOPIC_AMETE_ALEM = 11;

    private static final String[] calTypes = {
        "buddhist", 
	"chinese", 
	"coptic", 
	"ethiopic", 
	"gregorian", 
	"hebrew", 
        "indian", 
	"islamic", 
	"islamic-civil", 
	"japanese", 
	"roc", 
	"ethiopic-amete-alem"
    };

How to map between OS_MACOSX and ICU4J calendar specification ?
---------------------------------------------------------------
  In this case the mapping is straightforward:

kCFGregorianCalendar --> "gregorian"
kCFBuddhistCalendar --> "buddhist"
kCFChineseCalendar --> "chinese"
kCFHebrewCalendar --> "hebrew"
kCFIslamicCalendar --> "islamic"
kCFIslamicCivilCalendar --> "islamic-civil"
kCFJapaneseCalendar --> "japanese"

How to map between OS_WIN32 and ICU4J calendar specification ?
---------------------------------------------------------------
  In this case the mapping is less trivial. The suggested one is as follows:

CAL_GREGORIAN - Gregorian (localized) --> "gregorian"
CAL_GREGORIAN_US - Gregorian (English strings always) --> "gregorian"
CAL_JAPAN - Japanese Emperor Era --> "japanese"
CAL_TAIWAN - Taiwan Calendar --> "roc"
CAL_KOREA - Korean Tangun Era --> ? ( "gregorian" )
CAL_HIJRI - Hijri (Arabic Lunar) --> "islamic"
CAL_THAI - Thai --> ? ("buddhist", "gregorian")
CAL_HEBREW - Hebrew (Lunar) --> "hebrew"
CAL_GREGORIAN_ME_FRENCH - Gregorian Middle East French -->
CAL_GREGORIAN_ARABIC - Gregorian Arabic --> ? ("islamic-civil", "gregorian")
CAL_GREGORIAN_XLIT_ENGLISH - Gregorian transliterated English --> ? ( "gregorian" )
CAL_GREGORIAN_XLIT_FRENCH - Gregorian transliterated French --> ? ( "gregorian" )
CAL_UMALQURA - Windows Vista or later: Um Al Qura (Arabic lunar) calendar --> ? ( "gregorian" )
Comment 1 Tomer Mahlin CLA 2008-11-17 10:54:26 EST
Created attachment 118055 [details]
Selecting calendar preference for Korean locale on Windows OS
Comment 2 Tomer Mahlin CLA 2008-11-17 10:55:27 EST
Created attachment 118056 [details]
Selecting calendar preference on MAC OS
Comment 3 Tomer Mahlin CLA 2009-04-06 12:15:18 EDT
I am lowering the Severity since now there is a way to explicitly specify the calendar preference.
Comment 4 Eclipse Webmaster CLA 2019-09-06 15:30:43 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.