Testcases for NSDateFormatter


(Taylor Franklin) #1

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


(Philippe Hausler) #2

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> 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(Taylor Franklin) #3

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@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> 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> >> 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> 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@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@gmail.com
*Blog*: http://taylorfranklin.me | *LinkedIn*:
https://www.linkedin.com/in/taylorfranklin


(Philippe Hausler) #4

Some responses inline:

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.

···

On Feb 21, 2016, at 10:22 PM, Taylor Franklin <taylorleefranklin@gmail.com> wrote:

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, 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@swift.org <mailto:swift-corelibs-dev@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@gmail.com <mailto:taylorleefranklin@gmail.com>
Blog: http://taylorfranklin.me <http://taylorfranklin.me/> | LinkedIn: https://www.linkedin.com/in/taylorfranklin


(Taylor Franklin) #5

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

Some responses inline:

On Feb 21, 2016, at 10:22 PM, Taylor Franklin <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:
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@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> 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> >>> 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> 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@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@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@gmail.com
*Blog*: http://taylorfranklin.me | *LinkedIn*:
https://www.linkedin.com/in/taylorfranklin


(Philippe Hausler) #6

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@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: 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@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, 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@swift.org <mailto:swift-corelibs-dev@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 <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


(Taylor Franklin) #7

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

Some responses inline:

On Feb 21, 2016, at 10:22 PM, Taylor Franklin < >> 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:
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@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> 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> >>>> 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> 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@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@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@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@gmail.com
*Blog*: http://taylorfranklin.me | *LinkedIn*:
https://www.linkedin.com/in/taylorfranklin


(Will Stanton) #8

Hello Taylor,

If I understand what you’re asking, I feel like NS(Date/Number)Formatter property getters should be like:
CFDateFormatterCopyProperty(_cfObject, __CF_PROPERTY__)

Perhaps Philippe or Tony can confirm? Would like to know what they think.
(And while I’m at it: Any plans for CFAttributedString and write/read streams to become available?)

So, ex. for month symbols:
internal var _monthSymbols: [String]!
public var monthSymbols: [String]! {
    get {
            var symbols = Array<String>()
            let cfSymbols = CFDateFormatterCopyProperty(_cfObject, kCFDateFormatterMonthSymbols) as! NSArray
            for obj in cfSymbols {
                symbols.append((obj as! NSString)._swiftObject)
            }
            return symbols
    }
    set {
        _reset()
        _monthSymbols = newValue
    }
}

Perhaps there is a more efficient way to make a CFArray into an Array<String>…

Regards,
Will Stanton

···

On Feb 26, 2016, at 7:25 PM, Taylor Franklin via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

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


(Taylor Franklin) #9

Thanks for the response Will, that makes a lot of sense.
I will be sure to try something along the lines of your code snippet, this
weekend.

I could use a map function for creating the [String], but I'm not sure that
is more efficient.

Thanks again,
Taylor Franklin

···

On Fri, Feb 26, 2016 at 7:28 PM, Will Stanton <willstanton1@yahoo.com> wrote:

Hello Taylor,

If I understand what you’re asking, I feel like NS(Date/Number)Formatter
property getters should be like:
CFDateFormatterCopyProperty(_cfObject, __CF_PROPERTY__)

Perhaps Philippe or Tony can confirm? Would like to know what they think.
(And while I’m at it: Any plans for CFAttributedString and write/read
streams to become available?)

So, ex. for month symbols:
internal var _monthSymbols: [String]!
public var monthSymbols: [String]! {
    get {
            var symbols = Array<String>()
            let cfSymbols = CFDateFormatterCopyProperty(_cfObject,
kCFDateFormatterMonthSymbols) as! NSArray
            for obj in cfSymbols {
                symbols.append((obj as! NSString)._swiftObject)
            }
            return symbols
    }
    set {
        _reset()
        _monthSymbols = newValue
    }
}

Perhaps there is a more efficient way to make a CFArray into an
Array<String>…

Regards,
Will Stanton

> On Feb 26, 2016, at 7:25 PM, Taylor Franklin via swift-corelibs-dev < > swift-corelibs-dev@swift.org> wrote:
>
> Although, all that is unrelated to my latest question of getting some of
the NSDateFormatter properties their proper default values?

--
*Taylor Franklin*
iOS Developer | IBM Mobile Innovation Lab
972-207-2051 | taylorleefranklin@gmail.com
*Blog*: http://taylorfranklin.me | *LinkedIn*:
https://www.linkedin.com/in/taylorfranklin


(Philippe Hausler) #10

Just to confirm Will is on point for how it works - the only addendum is that if the internal object is not present it that it does regenerate the CFDateFormatter when that is nil.

In this case the iteration versus map has virtually no difference except for a stylistic choice.

roughly it would turn out like this:

cfSymbols.bridge().map { ($0 as! NSString).bridge() }

I have some outstanding work to bring in a few more things; I have some initial work for attributed strings but that has not been a priority in comparison to some of the other work we have been doing. I will see if I can get that posted here shortly so others can iterate on it.

···

On Feb 27, 2016, at 11:44 AM, Taylor Franklin <taylorleefranklin@gmail.com> wrote:

Thanks for the response Will, that makes a lot of sense.
I will be sure to try something along the lines of your code snippet, this weekend.

I could use a map function for creating the [String], but I'm not sure that is more efficient.

Thanks again,
Taylor Franklin

On Fri, Feb 26, 2016 at 7:28 PM, Will Stanton <willstanton1@yahoo.com <mailto:willstanton1@yahoo.com>> wrote:
Hello Taylor,

If I understand what you’re asking, I feel like NS(Date/Number)Formatter property getters should be like:
CFDateFormatterCopyProperty(_cfObject, __CF_PROPERTY__)

Perhaps Philippe or Tony can confirm? Would like to know what they think.
(And while I’m at it: Any plans for CFAttributedString and write/read streams to become available?)

So, ex. for month symbols:
internal var _monthSymbols: [String]!
public var monthSymbols: [String]! {
    get {
            var symbols = Array<String>()
            let cfSymbols = CFDateFormatterCopyProperty(_cfObject, kCFDateFormatterMonthSymbols) as! NSArray
            for obj in cfSymbols {
                symbols.append((obj as! NSString)._swiftObject)
            }
            return symbols
    }
    set {
        _reset()
        _monthSymbols = newValue
    }
}

Perhaps there is a more efficient way to make a CFArray into an Array<String>…

Regards,
Will Stanton

> On Feb 26, 2016, at 7:25 PM, Taylor Franklin via swift-corelibs-dev <swift-corelibs-dev@swift.org <mailto:swift-corelibs-dev@swift.org>> wrote:
>
> Although, all that is unrelated to my latest question of getting some of the NSDateFormatter properties their proper default values?

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


(Will Stanton) #11

Hello Philippe,

Great to hear, thanks - was not (am not?) sure CFAttributedString is going to be included in CFLite.

Taylor - happy I could help!

Regards,
Will Stanton

···

On Feb 27, 2016, at 2:50 PM, Philippe Hausler <phausler@apple.com> wrote:

I have some outstanding work to bring in a few more things; I have some initial work for attributed strings but that has not been a priority in comparison to some of the other work we have been doing. I will see if I can get that posted here shortly so others can iterate on it.


(Taylor Franklin) #12

Hey Philippe,

In looking over your last comment and trying to implement the various
getters, I'm not sure what you mean when you were talking about "the only
addendum". So if _monthSymbols is nil, I should regenerate the
CFDateFormatter?

The following seems to be working thus far:

    internal var _monthSymbols: [String]!
    public var monthSymbols: [String]! {
        get {
            var symbols = [String]()
            let cfSymbols = CFDateFormatterCopyProperty(_cfObject,
kCFDateFormatterMonthSymbols) as! NSArray
            symbols = cfSymbols.bridge().map { ($0 as! NSString).bridge() }
            return symbols
        }
        set {
            _reset()
            _monthSymbols = newValue
        }
    }

···

On Sat, Feb 27, 2016 at 2:41 PM, Will Stanton <willstanton1@yahoo.com> wrote:

Hello Philippe,

Great to hear, thanks - was not (am not?) sure CFAttributedString is going
to be included in CFLite.

Taylor - happy I could help!

Regards,
Will Stanton

> On Feb 27, 2016, at 2:50 PM, Philippe Hausler <phausler@apple.com> > wrote:
>
> I have some outstanding work to bring in a few more things; I have some
initial work for attributed strings but that has not been a priority in
comparison to some of the other work we have been doing. I will see if I
can get that posted here shortly so others can iterate on it.

--
*Taylor Franklin*
iOS Developer | IBM Mobile Innovation Lab
972-207-2051 | taylorleefranklin@gmail.com
*Blog*: http://taylorfranklin.me | *LinkedIn*:
https://www.linkedin.com/in/taylorfranklin