[swift-corelibs-dev] Calendar identifiers

[Pushkar N Kulkarni via swift-corelibs-dev]

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:   https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/Locale.subproj/CFCalendar.c#L239For 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. Thanks!Pushkar N Kulkarni,
IBM RuntimesSimplicity is prerequisite for reliability - Edsger W. Dijkstra


___
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Calendar identifiers

[Alex Blewitt via swift-corelibs-dev]

> On 4 Oct 2016, at 10:29, Pushkar N Kulkarni via swift-corelibs-dev 
>  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:
>
> 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
 

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

Re: [swift-corelibs-dev] Calendar identifiers

[Pushkar N Kulkarni via swift-corelibs-dev]

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, .republicOfChinaI 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#L56Pushkar N Kulkarni,
IBM RuntimesSimplicity is prerequisite for reliability - Edsger W. Dijkstra
-alb...@apple.com wrote: -To: Pushkar N Kulkarni/India/IBM@IBMINFrom: Alex Blewitt Sent by: alb...@apple.comDate: 10/04/2016 03:28PMCc: swift-corelibs-dev Subject: Re: [swift-corelibs-dev] Calendar identifiersOn 4 Oct 2016, at 10:29, Pushkar N Kulkarni via swift-corelibs-dev  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:   https://github.com/apple/swift-corelibs-foundation/blob/master/CoreFoundation/Locale.subproj/CFCalendar.c#L239For 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/c1d940dd6099de65f959fd42274cf0e65984efe0Of 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

Re: [swift-corelibs-dev] Calendar identifiers

[Philippe Hausler via swift-corelibs-dev]

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 
>  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  <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 
>> 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