[swift-corelibs-dev] Testcases for NSDateFormatter

Fri Feb 26 17:58:39 CST 2016

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

> Some responses inline:
>
>
> On Feb 21, 2016, at 10:22 PM, Taylor Franklin <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
>
>
> 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> 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
>
>
>

-- 
*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/20160226/f2d556a9/attachment.html>