directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (DIRAPI-219) DateUtils.toGeneralizedTime does not work with some Locales
Date Sun, 23 Aug 2015 09:03:45 GMT

    [ https://issues.apache.org/jira/browse/DIRAPI-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14708326#comment-14708326
] 

Uwe Schindler edited comment on DIRAPI-219 at 8/23/15 9:03 AM:
---------------------------------------------------------------

Hi thanks for the quick change! The above commit was not the one changing the calendar, so
I was a bit confused (it was the previous one): http://svn.apache.org/r1697148

This should now be fine, but a bit confusing, so I suggest to change this a bit:
- {{GregorianCalendar.getInstance}} does not exist, its a static method in {{Calendar}} (Eclipse
or PMD should print a warning about calling a static method on subclass). So either change
to {{Calendar.getInstance(Locale.ROOT)}} or {{Calendar.getInstance(Locale.ENGLISH)}}; or *much
better:*
- use the constructor: {{calendar = new GregorianCalendar(GMT, Locale.ROOT)}}. By that you
also don't need to use the setters and its explicit which calendar you want to use (see documentation
and BNF requiring GregorianCalendar)! Relying on the Locale is not correct, because suddenly
{{ENGLISH}} may change to another Calendar (this would be extreme - for sure, but we dont
want to rely on country or language here).

Thanks for investigating forbidden-apis, we implemented that because of such problems in Apache
Lucene and Solr whoich are very language agnostic, so it is very important to be explicit!
If you have any question we can help. It is also useful to "forbid" your own definitions.
E.g. our test framework does not allow threads/threadpools without names and this is also
enforced by the tool.


was (Author: thetaphi):
Hi thanks for the quick change! The above commit was not the one changing the calendar, so
I was a bit confused (it was the previous one): http://svn.apache.org/r1697148

This should now be fine, but a bit confusing, so I suggest to change this a bit:
- {{GregorianCalendar.getInstance}} does not exist, its a static method in {{Calendar}} (Eclipse
or PMD should print a warning about calling a static method on subclass). So either change
to {{Calendar.getInstance(Locale.ROOT)}} or {{Calendar.getInstance(Locale.ENGLISH)}}; *much
better:*
- use the constructor: {{calendar = new GregorianCalendar(GMT, Locale.ROOT)}}. By that you
also don't need to use the setters and its explicit which calendar you want to use (see documentation
and BNF requiring GregorianCalendar)! Relying on the Locale is not correct, because suddenly
{{ENGLISH}} may change to another Calendar (this would be extreme - for sure, but we dont
want to rely on country or language here).

Thanks for investigating forbidden-apis, we implemented that because of such problems in Apache
Lucene and Solr whoich are very language agnostic, so it is very important to be explicit!
If you have any question we can help. It is also useful to "forbid" your own definitions.
E.g. our test framework does not allow threads/threadpools without names and this is also
enforced by the tool.

> DateUtils.toGeneralizedTime does not work with some Locales
> -----------------------------------------------------------
>
>                 Key: DIRAPI-219
>                 URL: https://issues.apache.org/jira/browse/DIRAPI-219
>             Project: Directory Client API
>          Issue Type: Bug
>    Affects Versions: 1.0.0-M28
>            Reporter: Gregory Chanan
>             Fix For: 1.0.0-M29, 1.0.0-M32
>
>
> Over in SOLR-6915 I've run into an issue with a few Locales when trying to use Apache
Directory Server via the Hadoop MiniKDC.  Here's an example failure that happens on JDK8:
https://issues.apache.org/jira/browse/SOLR-6915?focusedCommentId=14287516&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14287516
> The locales that have a problem for me are:
> th_TH_TH_#u-nu-thai
> ja_JP_JP_#u-ca-japanese
> hi_IN
> I've tracked these problems to DateUtils.toGeneralizedTime(), which is returning the
following to me for these 3 locales, respectively:
>  ๒๕๕๘๐๑๒๗๐๑๐๘๐๖.๙๒๙Z
>  270127010806.259Z
> २०१५०१२७०१०८०६.०४०Z



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message