2017-10-04 10 views
2

Explicitement en utilisant withLocale pour définir les paramètres régionaux sur les résultats allemands dans la chaîne am/pm localisée dans la valeur de temps, mais pas convertir au format 24 heures qui est correct pour cette locale.L'utilisation de Joda DateTimeFormatter.withLocale() affecte uniquement la valeur de chaîne pour am/pm, pas le format d'heure

Lorsqu'un nouveau processus est créé, avec le Locale.setLocale(Locale.GERMAN); ayant été fait, le format est correct.

Est-ce que withLocale() ne devrait pas affecter tous les aspects des paramètres régionaux en question?

// Code snippet where call is being made: 
Log.d(TAG, "XYZZY getDefault(): " + Locale.getDefault().toString()); 
DateTimeFormatter timeFormat = DateTimeFormat.shortTime() 
      .withLocale(Locale.getDefault()); 
Log.d(TAG, "XYZZY timeFormat.locale: " + 
      timeFormat.getLocale().toString()); 
dateString = alarmTime.toString(timeFormat); 
Log.d(TAG, "XYZZY dateString: "+ dateString); 

Lorsque le alarmTime variable a une valeur de 23:00 (2300 heures):

10-04 14: 17: 41,492 (23609): XYZZY getDefault(): fr -04 14: 17: 41,493 (23609): XYZZY timeFormat.locale: en_US
10-04 14: 17: 41,495 (23609): XYZZY dateString: 23:00

maintenant passer aux paramètres régionaux allemands et réexécuter le même code, notez la chaîne des changements « PM » à l'allemand, mais pas le format de l'heure (le suffixe doit être supprimée et la valeur de temps doit être 23h00):

10-04 14:18 : 15,066 (23609): XYZZY getDefault(): de_DE
10-04 14: 18: 15,066 (23609): XYZZY timeFormat.locale: de_DE
10-04 14: 18: 15,067 (23609): XYZZY dateString: 11 : 00 nachm.

Attendez que le processus en aller et redémarrer, laissant les paramètres régionaux comme allemand, et maintenant le format de l'heure correcte pour l'allemand est retourné:

10-04 14: 18: 54,497 (23881): XYZZY getDefault(): de_DE
10-04 14: 18: 54,497 (23881): XYZZY timeFormat.locale: de_DE
10-04 14: 18: 54,498 (23881): XYZZY dateString: 23:00

+0

Comment créez-vous alarmTime à chaque fois? Et dans la parenthèse est le numéro le processus id? pourquoi est-ce la même chose pour le cas 1 et le cas 2 si vous avez de nouveau exécuté votre code? – Vahid

+0

Que le processus id est le même est le problème de base que je vois. Lorsque le processus disparaît et qu'un nouveau démarre (avec les paramètres régionaux en allemand), j'obtiens le résultat souhaité (cas 3). –

+0

pourriez-vous partager le code où vous créez le alarmTime? Et, vous développez pour Android? – Vahid

Répondre

0

Disclaimer: Pas une réponse, puisque je suis incapable de reproduire, mais écrit comme réponse pour montrer les détails de la façon dont j'ai essayé de reproduire le problème.

Je suis en cours d'exécution avec locale en_US dans le fuseau horaire America/New_York, en utilisant 1.8.0_91 et JDK Joda-Time 2.9.9.

test

LocalTime time = LocalTime.parse("23:00"); 
System.out.println(time); 
System.out.println(time.toString(DateTimeFormat.shortTime())); 
System.out.println(time.toString(DateTimeFormat.shortTime().withLocale(Locale.GERMANY))); 

Sortie

23:00:00.000 
11:00 PM 
23:00 

shortTime() fonctionne très bien, avec et sans changement de lieu.Les paramètres régionaux par défaut de la JVM n'ont jamais été modifiés.

+0

Merci pour cela, Andreas, je vais enquêter un peu plus sur la base de ce que vous montrez ici. J'utilise JDK 1.7.0_151, je ne sais pas quelle version de JodaTime (existe-t-il un moyen de découvrir ce programme?) –

+0

Ne sait pas, mais le nom du fichier jar a généralement le numéro de version. – Andreas

+0

@BillB Vous pouvez essayer 'DateTime.class.getPackage(). GetSpecificationVersion()' ou 'DateTime.class.getPackage(). GetImplementationVersion()'. Quoi qu'il en soit, j'ai aussi essayé de reproduire le problème (JDK 1.7.0_80 dans Eclipse), sans succès. Peut-être que c'est quelque chose de spécifique à Android. –