[swift-corelibs-dev] Calendar identifiers

[Philippe Hausler]

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 at 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
> 
> 
> 
> -----alblue at apple.com <mailto:-----alblue at apple.com> wrote: -----
> To: Pushkar N Kulkarni/India/IBM at IBMIN
> From: Alex Blewitt 
> Sent by: alblue at apple.com <mailto:alblue at apple.com>
> Date: 10/04/2016 03:28PM
> Cc: swift-corelibs-dev <swift-corelibs-dev at swift.org <mailto:swift-corelibs-dev at 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 at swift.org <mailto:swift-corelibs-dev at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20161004/a16d5d69/attachment.html>