[swift-corelibs-dev] Testcases for NSDateFormatter

Philippe Hausler phausler at apple.com
Fri Feb 26 18:10:37 CST 2016 

NSLocale as nil infers the current locale so that might be what is missing. Since the Objective-C implementation’s behavior is the standard to judge against it is reasonable to check in tests that fail (preferably disabled so that CI passes and a bug associated with it if you are uncertain of the correct implementation).

There was recently a merged pull request that changed some of this iirc: https://github.com/apple/swift-corelibs-foundation/commit/89556789cf1003dfa137eec9eed43ed965f3ea74

> On Feb 26, 2016, at 3:58 PM, Taylor Franklin <taylorleefranklin at gmail.com> wrote:
> 
> Philippe,
> 
> Thanks for the response, in working on NSDateFormatter, I have noticed that using the _cfObject will cause a runtime error if locale is simply nil and has no default value. With that said, not sure how to prove in a test since it crashes.
> 
> I did have another question though, I am unsure as how or where some of the NSDateFormatter properties get their initial values.
> For example, using the production version of Foundation and printing the .weekdaySymbols property gives me:
> ["Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"]
> 
> While in the development version of Foundation, that property is never set. Do you have any insights on where those default weekday values come from given a user's current locale? I assume the answer would apply to other properties like longEraSymbols, veryShortMonthSymbols, etc. 
> 
> Thanks,
> Taylor
> 
> 
> On Mon, Feb 22, 2016 at 11:10 AM, Philippe Hausler <phausler at apple.com <mailto:phausler at apple.com>> wrote:
> Some responses inline:
> 
> 
>> On Feb 21, 2016, at 10:22 PM, Taylor Franklin <taylorleefranklin at gmail.com <mailto:taylorleefranklin at gmail.com>> wrote:
>> 
>> Thanks Joe,
>> 
>> I will probably end up taking some of your work and execute Philippe's suggestion of testing with a dictionary. In the process of adding tests, hopefully I can improve NSDateFormatter over the next few weeks.
> 
> Awesome, feel free to reach out if you have questions on the appropriate behaviors/edge cases.
> 
>> 
>> @Philippe, I did have a question:
>> 
>> Currently, many of the properties, such as locale, look like this:
>> 
>> /*@NSCopying*/ public var locale: NSLocale! { willSet { _reset() } }
> 
> This was changed to support the willSet pre-operation.
> 
>> 
>> When previously, the looked like this:
>> 
>> internal var _locale: NSLocale = NSLocale.currentLocale()
>> /*@NSCopying*/ public var locale: NSLocale! {
>>     get {
>>         return _locale
>>     }
>>     set {
>>         _reset()
>>         _locale = newValue
>>     }
>> }
>> 
>> Do you know a reason for this change? It seems mostly the same except the there is no default value set anymore.
>> The pull request I'm referring to that made these changes is this: https://github.com/apple/swift-corelibs-foundation/pull/234 <https://github.com/apple/swift-corelibs-foundation/pull/234>
> The change should have been a non-functional change; if there are behavioral differences it is definitely a bug. The original version of that was written to be very close to the objective-c version (to the point that I actually inadvertently replicated a few bugs…)
> 
> If you can show via test that the behavior is different we can look into reverting/fixing date formatter.
> 
>> 
>> Thanks!
>> Taylor
>> 
>> On Sun, Feb 21, 2016 at 7:17 AM, Joseph Bell <joe at iachieved.it <mailto:joe at iachieved.it>> wrote:
>> Ah, I didn't even submit a pull request - that's how distracted I've been.  Again, the code is all yours to rework or base off of if you so choose.
>> 
>> On Sun, Feb 21, 2016 at 7:14 AM, Joseph Bell <joe at iachieved.it <mailto:joe at iachieved.it>> wrote:
>> Thanks Taylor.  Unfortunately I lost time and interest in taking the idea further, I just need to figure out how to withdraw the pull request.  Feel free to take the implementation and rework per Philippe's suggestions!
>> 
>> Joe
>> 
>> 
>> On Fri, Feb 19, 2016 at 6:35 PM, Philippe Hausler <phausler at apple.com <mailto:phausler at apple.com>> wrote:
>> The problem with the change in that commit is that it is doing two different things: it is testing against python which is not the definition of Foundation’s expected output instead of testing against the expected output from the objective-c implementation. My suggestion in the pull request was to just encode a dictionary of dates to strings sampling a well known range before hand. This way it would be verifiable on both linux and Darwin as “correct” in accordance with the version of Foundation.framework that ships on Mac OS X and iOS. 
>> 
>> The rest of the additions seemed pretty reasonable to me, except the case of calling popen to run a secondary script that may take extra execution time and add extra complexity other than just a dictionary of some good example date to string conversions (which actually could be utilized to reverse the test as well for scanning).
>> 
>>> On Feb 19, 2016, at 4:13 PM, Taylor Franklin via swift-corelibs-dev <swift-corelibs-dev at swift.org <mailto:swift-corelibs-dev at swift.org>> wrote:
>>> 
>>> Hello,
>>> 
>>> Are there any plans to integrate this commit into the main repo because I would love build off of the code within it, seeing that NSDateFormatter still seems incomplete. Additionally, the issue mentioned earlier, https://bugs.swift.org/browse/SR-208 <https://bugs.swift.org/browse/SR-208>, is still valid with the latest code from master.
>>> 
>>> In fact, stringFromDate doesn't seem to be doing much at all. Anyway, I would love to hear more from Joe or an admin on plans and progress for NSDateFormatter.
>>> 
>>> Thanks,
>>> Taylor Franklin
>>> 
>>> > Howdy,
>>> > 
>>> > A few weeks ago I opened https://bugs.swift.org/browse/SR-208 <https://bugs.swift.org/browse/SR-208> as it appears
>>> > setting the dateFormat property of NSDateFormatter has no effect. It's
>>> > been open for a while and I thought I'd start looking at whether or not I
>>> > could help, and decided to first start with getting NSDateFormatter
>>> > included in TestFoundation.
>>> > 
>>> > Before moving on further and issuing a PR, I would appreciate feedback on
>>> > the approach that I'm taking here:
>>> > 
>>> > https://github.com/iachievedit/swift-corelibs-foundation/commit/482d861127e8b78007ceaf15f6c905ac04b1e9a4 <https://github.com/iachievedit/swift-corelibs-foundation/commit/482d861127e8b78007ceaf15f6c905ac04b1e9a4>
>>> > 
>>> > The first tests are only looking at the dateStyle property, and I've
>>> > included tests for the various styles as they are rendered for the en_US
>>> > locale. The intent is to add support for validating additional locales in
>>> > the future.
>>> > 
>>> > Since strptime doesn't appear to be available to the Glibc module I'm using
>>> > a quick Python script included in Resources/ to take a format string and
>>> > render a human-friendly date.
>>> > 
>>> > At the moment I know there is a discrepancy between what NSDateFormatter
>>> > and the python driver can emit, the python script is currently adjusting to
>>> > my timezone and not using UTC, but that will be fixed before a PR is
>>> > issued. I'll also add the timeStyle property and then continue to add
>>> > tests.
>>> > 
>>> > Thoughts and comments most welcome, and Happy New Year.
>>> > 
>>> > Joe
>>> > 
>>> > 
>>> > 
>>> _______________________________________________
>>> swift-corelibs-dev mailing list
>>> swift-corelibs-dev at swift.org <mailto:swift-corelibs-dev at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev <https://lists.swift.org/mailman/listinfo/swift-corelibs-dev>
>> 
>> 
>> 
>> 
>> -- 
>> ---
>> http://dev.iachieved.it/iachievedit/ <http://dev.iachieved.it/iachievedit/>
>> @iachievedit
>> 
>> 
>> 
>> -- 
>> ---
>> http://dev.iachieved.it/iachievedit/ <http://dev.iachieved.it/iachievedit/>
>> @iachievedit
>> 
>> 
>> 
>> -- 
>> Taylor Franklin
>> iOS Developer | IBM Mobile Innovation Lab
>> 972-207-2051 <tel:972-207-2051>  | taylorleefranklin at gmail.com <mailto:taylorleefranklin at gmail.com>
>> Blog: http://taylorfranklin.me <http://taylorfranklin.me/> | LinkedIn: https://www.linkedin.com/in/taylorfranklin <https://www.linkedin.com/in/taylorfranklin>
> 
> 
> 
> -- 
> Taylor Franklin
> iOS Developer | IBM Mobile Innovation Lab
> 972-207-2051  | taylorleefranklin at gmail.com <mailto:taylorleefranklin at gmail.com>
> Blog: http://taylorfranklin.me <http://taylorfranklin.me/> | LinkedIn: https://www.linkedin.com/in/taylorfranklin <https://www.linkedin.com/in/taylorfranklin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20160226/ee682dda/attachment.html>

More information about the swift-corelibs-dev mailing list