On Feb 26, 2016, at 3:58 PM, Taylor Franklin <taylorleefranklin@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@apple.com <mailto:phausler@apple.com>> wrote:
Some responses inline:
On Feb 21, 2016, at 10:22 PM, Taylor Franklin <taylorleefranklin@gmail.com <mailto:taylorleefranklin@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: Tidy up NSDateFormatter by stephencelis · Pull Request #234 · apple/swift-corelibs-foundation · GitHub
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@iachieved.it <mailto:joe@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@iachieved.it <mailto:joe@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@apple.com <mailto:phausler@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@swift.org <mailto:swift-corelibs-dev@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, [SR-208] Setting .dateFormat of NSDateFormatter has no effect · Issue #4375 · apple/swift-corelibs-foundation · GitHub, 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 [SR-208] Setting .dateFormat of NSDateFormatter has no effect · Issue #4375 · apple/swift-corelibs-foundation · GitHub 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:
>
> NSDateFormatter tests · iachievedit/swift-corelibs-foundation@482d861 · GitHub
>
> 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@swift.org <mailto:swift-corelibs-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
--
---
iAchieved.it – Thoughts from a Technology Leader
@iachievedit
--
---
iAchieved.it – Thoughts from a Technology Leader
@iachievedit
--
Taylor Franklin
iOS Developer | IBM Mobile Innovation Lab
972-207-2051 <tel:972-207-2051> | taylorleefranklin@gmail.com <mailto:taylorleefranklin@gmail.com>
Blog: http://taylorfranklin.me <http://taylorfranklin.me/> | LinkedIn: https://www.linkedin.com/in/taylorfranklin
--
Taylor Franklin
iOS Developer | IBM Mobile Innovation Lab
972-207-2051 | taylorleefranklin@gmail.com <mailto:taylorleefranklin@gmail.com>
Blog: http://taylorfranklin.me <http://taylorfranklin.me/> | LinkedIn: https://www.linkedin.com/in/taylorfranklin