Comment puis-je définir le format de date NLS sans définir le paramètre régional

Question

Notre classe java appelle PLSQL proc qui renvoie la date au format par défaut définie par NLS_DATE_FORMAT. Notre application définit son propre Locale pour l'internationalisation mais je veux que le format de date reste juste 'DD-MON-RR' qui est en_US Locale NLS_DATE_FORMAT. En raison de la modification de la chaîne de date récupérée de l'environnement local oracle, elle diffère et les appels de fonction TO_DATE() suivants échouent. J'ai essayé de corriger cela en changeant Locale to Locale.setDefault(new Locale("en","US")); //"en_US" en classe Java et ça marche bien, mais la partie internationalisation ne marchera plus. Je suis à Singapour, donc mon Locale est "en_SG" et le format de la date que l'oracle suppose après le réglage NLS_TERRITORY: SINGAPORE est NLS_DATE_FORMAT:'DD/MM/RR'. Je interroge le serveur pour V $ NLS_PARAMETERS et là le format de date par défaut est 'DD-MON-RR'. Donc ma question est, puis-je définir le NLS_DATE_FORMAT sans affecter les paramètres régionaux de l'application. Ou puis-je faire en sorte que le pilote jdbc ignore les paramètres NLS du client?

Answer 1

Yo peut utiliser la fonction to_char pour formater la date que vous le souhaitez, vous pouvez également inclure le troisième paramètre dans to_char fonction pour désigner locale utilisée:

select to_char(sysdate, 'DY-MM-YYYY', 'NLS_DATE_LANGUAGE=AMERICAN') from dual; 

Plus d'informations sur les formats de date se trouve dans SQL Reference.

Answer 2

Je suis un peu en train de finaliser sur les choses i18n pour mon application et ma conception est basée sur des hypothèses ci-dessous)

1) Locale.setDefault (nouvelle Locale ("en", "US")); est mauvais car vous modifiez les paramètres régionaux par défaut pour la JVM et pas seulement pour votre application. Il est donc préférable de passer la locale autour de l'application sur une base de demande (peut être threadlocal)

2) Gérer tout le formatage/analyse i18n au niveau de l'application. DB ne doit gérer que les comparaisons (optionnellement), le tri (optionnel) et le stockage. Il suffit donc de définir NLS_CHARACTERSET, NLS_COMP, NLS_SORT et NLS_LENGTH_SEMANTICS. Par ailleurs, la comparaison et le tri au niveau db signifient la création d'index spécifiques aux paramètres régionaux ralentissant ainsi les insertions/mises à jour