[swift-corelibs-dev] Testcases for NSDateFormatter

Fri Feb 26 18:25:04 CST 2016

Oh right, I saw that pull request shortly after I sent my last message. It
seems hpux735 also thought locale needed to be initialized. I will follow
the process you mentioned in the future, if I have a similar issue.

Although, all that is unrelated to my latest question of getting some of
the NSDateFormatter properties their proper default values?

On Fri, Feb 26, 2016 at 6:10 PM, Philippe Hausler <phausler at apple.com>
wrote:

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

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