[
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)
