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
Pushkar N Kulkarni,
IBM Runtimes
Simplicity is prerequisite for reliability - Edsger W. Dijkstra
-----alb...@apple.com wrote: -----
To: Pushkar N Kulkarni/India/IBM@IBMIN
From: Alex Blewitt
Sent by: alb...@apple.com
Date: 10/04/2016 03:28PM
Cc: swift-corelibs-dev <swift-corelibs-dev@swift.org>
Subject: Re: [swift-corelibs-dev] Calendar identifiers
From: Alex Blewitt
Sent by: alb...@apple.com
Date: 10/04/2016 03:28PM
Cc: swift-corelibs-dev <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> 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)For the Calendar initialiser "init(identifier: Calendar.Identifier)", the possible values of Calendar.Identifier are listed here. 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: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:
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
