JDK-4052414 : RFE: Traditional Calendars
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 1.1.2
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_nt
  • CPU: x86
  • Submitted: 1997-05-15
  • Updated: 2000-02-14
  • Resolved: 2000-02-14
Related Reports
Duplicate :  
JDK-4107213 - Add support for variants in locales
Duplicate :  
JDK-4071770 - RFE: Need era support for Japanese and Taiwanese dates
Duplicate :  
JDK-4284932 - International Calendars
Description

Name: bb33257			Date: 05/15/97


- Calendar needs a static final to indicate the last field. 

- Need API on Calendar to pick Gregorian vs Traditional 
calendars, and information in the locale to indicate which 
is the default. Need additional traditional
calendars: Japanese, Arabic Lunar, Hebrew Lunar, Thai.
======================================================================
Comments
WORK AROUND Name: bb33257 Date: 05/15/97 ======================================================================
11-06-2004
EVALUATION Request for static to indicate last field is already fixed (for some time). Remaining problem is RFE for variants inside locales. -alanl mark.son-bell@eng 1998-03-25 The remaining RFE in this bug report is for traditional-calendar support, which doesn't actually need the locale-variant mechanism. (it could be done the same way Euro support is being handled.) However, adding support for traditional calendars will probably involve other API additions. A separate RFE (#4052414) has been openned for locale variants. I am reassigning this to Laura Werner, who has already implemented several traditional Calendars. alan.liu@eng 1998-10-29 I don't think any new APIs should be introduced to support traditional calendards, assuming that traditional means things covered by the XPG/ISO C spec. In case we introduce new APIs, who decide to use the traditional calendar? Application developers? L10N? End users? masayoshi.okutsu@Eng 1999-04-12 This is not exactly the same request. But I'm closing this as a duplicate of 4071770. masayoshi.okutsu@Eng 2000-02-14
12-04-1999