[swift-corelibs-dev] Testcases for NSDateFormatter

[Taylor Franklin]

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.

@Philippe, I did have a question:

Currently, many of the properties, such as locale, look like this:

/*@NSCopying*/ public var locale: NSLocale! { willSet { _reset() } }

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

Thanks!
Taylor

On Sun, Feb 21, 2016 at 7:17 AM, Joseph Bell <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> 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>
>> 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> 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, 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 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
>>> >
>>> > 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
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>>>
>>>
>>>
>>
>>
>> --
>> ---
>> http://dev.iachieved.it/iachievedit/
>> @iachievedit
>>
>
>
>
> --
> ---
> http://dev.iachieved.it/iachievedit/
> @iachievedit
>



-- 
*Taylor Franklin*
iOS Developer | IBM Mobile Innovation Lab
972-207-2051  | taylorleefranklin at gmail.com
*Blog*: http://taylorfranklin.me | *LinkedIn*:
https://www.linkedin.com/in/taylorfranklin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20160222/aa2e1c93/attachment.html>