NSDateFormatter nie pokazuje skrótu strefy czasowej dla "Azja/Kolkata" dla specyfikatora "z" lub "zzz", tylko przesunięcie GMT

Question

Na symulatorze i urządzeniu iOS5, NSDateFormatter nie pokazuje skrótu strefy czasowej dla "Azja/Kalkuta "dla specyfikatora" z "lub" zzz ".

NSTimeZone *timeZone = [NSTimeZone timeZoneWithName:@"Asia/Kolkata"]; 
NSDateFormatter *dateFormatter = [[[NSDateFormatter alloc] init] autorelease]; 
dateFormatter.dateFormat = @"z"; // or @"zzz" 
dateFormatter.timeZone = timeZone; 

NSLog(@"date string: %@", [dateFormatter stringFromDate:[NSDate date]]); // "GMT+05:30", expected "IST" 
NSLog(@"time zone abbreviation: %@", [timeZone abbreviationForDate:[NSDate date]]); // "IST" 

Spodziewam powyższy kod do wyjścia:

IST 
IST 

ale wyprowadza:

GMT+05:30 
IST 

EDIT

Ustawienie locale do indian lokalizacji nie wydaje się pomagać.

NSLocale *indianEnglishLocale = [[[NSLocale alloc] initWithLocaleIdentifier:@"en_IN"] autorelease]; 
NSTimeZone *timeZone = [NSTimeZone timeZoneWithName:@"Asia/Kolkata"]; 
NSDateFormatter *dateFormatter = [[[NSDateFormatter alloc] init] autorelease]; 
[dateFormatter setLocale:indianEnglishLocale]; 
[dateFormatter setDateFormat:@"z"]; // or @"zzz" 
[dateFormatter setTimeZone:timeZone]; 

NSLog(@"date string: %@", [dateFormatter stringFromDate:[NSDate date]]); // "GMT+05:30", expected "IST" 
NSLog(@"time zone abbreviation: %@", [timeZone abbreviationForDate:[NSDate date]]); // "IST" 

Spodziewam powyższy kod do wyjścia:

IST 
IST 

ale wyprowadza:

GMT+05:30 
IST 

Czy to błąd? czy robię coś źle? People have mentioned that NSDateFormatter has bugs, especially when a time zone is specified in the format string. Could this be one of those bugs?

Answer 1

Od http://www.cocoabuilder.com/archive/cocoa/310977-nsdateformatter-not-working-on-ios-5.html#311281

Zmiana parsowania skróconych nazw stref czasowych w iOS 5.0 jest wynikiem celowej zmiany OIOM open-source 4,8 biblioteka (i open-source CLDR 2.0 dane, których używa), zmodyfikowana wersja z której jest używana do implementacji niektórych funkcji NSDateFormatter .

Kwestia jest taka: Z krótkich formatów strefy czasowej określonymi przez Z (= zzz) lub V (= VVV), nie może być wiele niejasności. Na przykład "ET" dla czasu wschodniego "może mieć zastosowanie do różnych stref czasowych w różnych różnych regionach Aby poprawić formatowanie i niezawodność analizowania, krótkie formularze są używane tylko w ustawieniach narodowych, jeśli flaga" cu "(powszechnie używana) jest ustawiony dla danej lokalizacji. w przeciwnym razie stosowane są tylko długie formularze (dla zarówno formatowania i analizowania).

dla „en” locale (= „pl”), flaga cu jest ustawiony na metazones takich jako Alaska, America_Central, America_Eastern, America_Mountain, America_Pacific, Atlantic, Hawaii_Aleutian, i GMT To jest nie zestaw dla Europe_Central

Jednak w przypadku ustawienia "en_GB" flaga cu jest ustawiona na dla Europe_Central.

Więc formater ustawiony na krótki stylu czasowej „Z” lub „zzz” i locale „en” lub „pl” nie będzie analizować „CEST” lub „CET”, ale jeśli locale jest zamiast ustawienie " en_GB "to będzie przeanalizować te. Styl "GMT" zostanie przeanalizowany przez wszystkie.

Jeśli formater jest ustawiony na dłuższej stylu czasowej „zzzz” i locale jest jakaś „en”, „pl” lub „en_GB”, a następnie jedną z poniższych będzie analizowany, ponieważ są jednoznaczne: "Pacyficzny czas letni" "Środkowoeuropejski czas letni" "Czas środkowoeuropejski"

Mam nadzieję, że to pomoże.

• Peter Edberg

Od http://www.cocoabuilder.com/archive/cocoa/313301-nsdateformatter-not-working-on-ios-5.html#313301

Heath, Tak, masz rację, na przykład podany powyżej, [dateFormatter stringFromDate: [data NSDate]] powinien użyć krótkiej nazwy strefy czasowej "IST". Fakt, że nie jest spowodowana niedoborem w „en_in” danych locale w wersjach danych wykorzystywanych przez CLDR OIOM w bieżące OSX i iOS uwolnień (CLDR 1.9.1 i 2.0, odpowiednio). W „en_in” locale w tych wersjach CLDR nie zastępują lub uzupełniają jakichkolwiek danych nazw stref czasowych od podstawy „en” Locale, którego treść domyślną jest dla „pl”.

Zostało to już poprawione, ponieważ wydanie CLDR 21 nastąpi za kilka dni. która jest włączona do OIOM 49, które będą zbierane w przyszłych wydań OSX i iOS.

• Peter E

--- Edit ---

Zgodnie z dokumentacją unicode na formats i ich rules sformatować V mogło być lepszym wyborem:

... ten sam f ormat jako Z tym wyjątkiem, że strefy czasowej metazone skróty mają być wyświetlane, jeśli są dostępne, niezależnie od wartości w [tym] commonlyUsed [flaga].

W moim przypadku, z następującego kodu:

NSLocale *indianEnglishLocale = [[[NSLocale alloc] initWithLocaleIdentifier:@"en_IN"] autorelease]; 
NSTimeZone *timeZone = [NSTimeZone timeZoneWithName:@"Asia/Kolkata"]; 
NSDateFormatter *dateFormatter = [[[NSDateFormatter alloc] init] autorelease]; 
[dateFormatter setLocale:indianEnglishLocale]; 
[dateFormatter setDateFormat:@"V"]; 
[dateFormatter setTimeZone:timeZone]; 

NSLog(@"V date string: %@", [dateFormatter stringFromDate:[NSDate date]]); 

I pojawia się następujący komunikat:

V date string: IST