Pushkar N Kulkarni,
IBM Runtimes
Simplicity is prerequisite for reliability - Edsger W. Dijkstra
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:
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.
I've hit an obstacle while working on a crash seen in initing a Calendar (https://bugs.swift.org/browse/SR-2551))
Hi there,
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
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
···
On 4 Oct 2016, at 10:29, Pushkar N Kulkarni via swift-corelibs-dev swift-corelibs-dev@swift.org wrote:
To: Pushkar N Kulkarni/India/IBM@IBMIN
From: Alex Blewitt
Sent by: alblue@apple.com
Date: 10/04/2016 03:28PM
Cc: swift-corelibs-dev swift-corelibs-dev@swift.org
Subject: Re: [swift-corelibs-dev] Calendar identifiers
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
-----alblue@apple.com wrote: -----