The definition should be; NSString * const kCFCalendarIdentifierISO8601 = @"iso8601”;
It was likely empty since it was probably un-implemented. > On Oct 4, 2016, at 8:34 AM, Pushkar N Kulkarni via swift-corelibs-dev > <swift-corelibs-dev@swift.org> wrote: > > Hi Alex, > > Thanks for your response. > > This failure doesn't happen with ISO8601 alone. There are half a dozen > identifiers that aren't supported. Having said that, I added these > identifiers to that if-statement and the calendar initialization did happen: > > .indian, .islamicTabular, .islamicUmmAlQura, .iso8601, .persian, > .republicOfChina > > I am not sure if they would cause any other problems thought. > > Another thing I got curious about: Why is NSCalendar.Identifier.ISO8601 > associated with an empty string here (it doesn't really matter, I guess)? > https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSCalendar.swift#L56 > > <https://github.com/apple/swift-corelibs-foundation/blob/master/Foundation/NSCalendar.swift#L56> > > > Pushkar N Kulkarni, > IBM Runtimes > > Simplicity is prerequisite for reliability - Edsger W. Dijkstra > > > > -----alb...@apple.com <mailto:-----alb...@apple.com> wrote: ----- > To: Pushkar N Kulkarni/India/IBM@IBMIN > From: Alex Blewitt > Sent by: alb...@apple.com <mailto:alb...@apple.com> > Date: 10/04/2016 03:28PM > Cc: swift-corelibs-dev <swift-corelibs-dev@swift.org > <mailto:swift-corelibs-dev@swift.org>> > Subject: Re: [swift-corelibs-dev] Calendar identifiers > > >> On 4 Oct 2016, at 10:29, Pushkar N Kulkarni via swift-corelibs-dev >> <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote: >> >> Hi there, >> >> I've hit an obstacle while working on a crash seen in initing a Calendar >> (https://bugs.swift.org/browse/SR-2551) >> <https://bugs.swift.org/browse/SR-2551)> >> >> For the Calendar initialiser "init(identifier: Calendar.Identifier)", the >> possible values of Calendar.Identifier are listed here >> <https://developer.apple.com/reference/foundation/calendar.identifier>. >> However, we eventually end up calling >> "_CFCalendarInitWithIdentifier(CFCalendarRef calendar, CFStringRef >> identifier)" and the latter works only for a specific set of calendar >> identifiers. See this if statement: >> >> https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/Locale.subproj/CFCalendar.c#L239 >> >> <https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/Locale.subproj/CFCalendar.c#L239> >> >> For other identifier values, we crash (that is SR-2551). On mac, all the >> identifier values are supported. It seems that the calendar identifier is >> ultimately encoded as a key-value pair in the locale ID for the calendar. >> >> Can anybody please help me understand the rationale of the if-statement >> above? I am new to ICU. I did search for justifications but didn't come >> across convincing. > > The if statement is canonicalising the reference to the constant e.g. > kCFCalendarIdentifierBuddhist. This allows other instances to be passed in > but then resolved to the same instance, such that pointer comparisons work > for future calls. The same is done for Swift. > > On macOS, there are additional checks in the CoreFoundation equivalent (such > as kCFCalendarIdentifierISO8601) which is why it works on Darwin. However, I > don't know if there were specific reasons for excluding the ISO8601 calendar, > unless the ICU library doesn't understand it. Testing adding support should > be a case of doing something similar to this commit, which re-enabled the > Chinese calendar: > > https://github.com/apple/swift-corelibs-foundation/commit/c1d940dd6099de65f959fd42274cf0e65984efe0 > > <https://github.com/apple/swift-corelibs-foundation/commit/c1d940dd6099de65f959fd42274cf0e65984efe0> > Of course building with the 'if' switch enabled may highlight other issues, > but on a quick test build it seems that adding the additional if case to the > statement results in the ISO8601 calendar being returned. I'll let others > explain in more detail if there's some specific subtlety for why it was left > out in the first place. > > Alex > > _______________________________________________ > swift-corelibs-dev mailing list > swift-corelibs-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
_______________________________________________ swift-corelibs-dev mailing list swift-corelibs-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
