Add support for <input type="date"/>

[benlesh]

This is to at least partially address #757

The idea is to add support for existing HTML5 implementations of <input type="date"/> while supporting a text version for older browsers that handles the appropriate HTML5 validations.

Additionally, an Angular-specific attribute was added (ng-output-date) to give the developer the option to output the value to the model as a Date object rather than the default string.

All string are expected in the HTML spec compliant ISO-8601 date strings: 'YYYY-MM-DD'

Hopefully this lays the groundwork for other similar input types such at datetime, month, datetime-local, etc.

[mary-poppins]

Thanks for the PR!

• Contributor signed CLA now or in the past
  • If you just signed, leave a comment here with your real name
• PR's commit messages follow the commit message format

If you need to make changes to your pull request, you can update the commit with git commit --amend.
Then, update the pull request with git push -f.

Thanks again for your help!

[benlesh]

I've signed the CLA in the past. Resigned today for good measure (I'm not sure if it's changed). PR commit messages should be in order (but I won't be hurt if they need tweaked).

Looking forward to feedback. This is based off of work I had to do for another project, and it worked out well there. Even though there it was in a separate module and .js file.

[benlesh]

To be clear, this is not an attempt at a polyfill. It just adds basic validation handling and some binding niceties for Angular.

[tbosch]

Hi,
I am sorry but we won't include this into angular-core. E.g. we would have to:

• support older browsers
• support all locale bundles of angular
• implement a date parser for all of those locals

I agree this would be nice to have, but not within angular-core.
Closing this...

[benlesh]

Support older browsers... sure. how old? Which browsers?

Support all locale bundles? Why does it need to support locale bundles? This is not a polyfill. It's an implementation to tie Angular validation to the HTML spec in a simple way. Nearly identical to the handling of the input of type "number".

Implement a date parser for all those locales? Again, I'm not really sure I follow. The HTML spec states the ISO-8601 format is what's accepted (YYYY-MM-dd).

The format is to the W3C HTML spec found here. Which states that output from input of type "date" should be ISO-8601 or "YYYY-MM-dd".

value = date #
A string representing a date.
A valid full-date as defined in [RFC 3339], with the additional qualification that the year component is four or >more digits representing a number greater than 0.
Example:
1996-12-19

Was this a unilateral decision to close this or was there a discussion? It seems the spirit of the pull request has been missed.

I'm willing to iterate on this pull request until there's something viable by Angular standards as a starting point.

Additional reading:

• http://www.w3.org/TR/html-markup/input.date.html
• http://www.ietf.org/rfc/rfc3339.txt

[tbosch]

Hi,
first, sorry, I didn't want to offend you and we really appreciate your input!

So yes, there was a discussion around this.

Older browsers that don't support type="date", e.g.:

• IE9
• Stock Browser on Android 2.3

If Angular supports type="date" it should support it on all browsers that are supported by Angular (just like type="number"). On those older browsers type="date" degrades to a type="text", and with this PR people would have to enter the date in ISO date format and without a date picker, which is not very usable. Instead, people should be able to enter the date in their current locale's date format, just like modern browsers allow them to. We already have the date format for all supported locales due to the date filter. However, we would need a date parser that reads out the date format of the locale and applies it to the text entered in the input.

If you want to add those missing peaces I would be happy to support you in this.

[benlesh]

Sounds great. I'll work on it.
On Dec 4, 2013 7:18 PM, "Tobias Bosch" notifications@github.com wrote:

Reopened #5256 #5256.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/5256
.

[IgorMinar]

please use getTime() instead to make the code readable.

[IgorMinar]

I added a few comments to the PR. I tested the behavior of the date input and it appears that at least chrome formats the date using users current locale. this formatting doesn't seem to be configurable.

From other browsers at least opera uses the ISO format instead of locale-specific formatting.

While these inconsistencies are not great, the fact that we can't affect the formatting in chrome anyway makes me think that we could take this PR as is.

the biggest issue I have with the current change is the ng-output-date api, which has no precedence in angular.

[benlesh]

please use getTime() instead to make the code readable.

I assume you're talking about the function name getDateValue? No problem. Although it's purpose was to get a millisecond value from an ISO string or date.

we have no precedence for an api like ng-output-date. is this feature required in the first iteration? could we drop it for now?

Absolutely. It was added to the pull request as more of a proposal. Since the HTML spec says it wants ISO date strings, but parsing those out to dates is going to be a really common practice. Perhaps a date parsing service at a later time would be a better approach?

please use a descriptive controller name and the "controller as" syntax

Sure. Didn't think about it.

I tested the behavior of the date input and it appears that at least chrome formats the date using users current locale. this formatting doesn't seem to be configurable.

@IgorMinar That's interesting, so you're saying the output of the input (ha) type "date" in Chrome isn't always ISO-8601? (yyyy-MM-dd)

indentation looks incorrect in all of the tests

For point of reference, I couldn't find (or I skimmed past, more likely) your formatting preferences for the project. I wanted to set my IDE (WebStorm) to have the same preference so auto-formatting doesn't blow up commits with superfluous line changes. I'm a compulsive auto-formatter so I've been fighting the urge. ;)

Locale and formatting

As far as formatting goes, my plan for the next iteration on this is to leverage $locale and parse each of the format types, for example:

"fullDate": "EEEE, MMMM d, y",
"longDate": "MMMM d, y",
"medium": "MMM d, y h:mm:ss a",
"mediumDate": "MMM d, y",
"mediumTime": "h:mm:ss a",
"short": "M/d/yy h:mm a",
"shortDate": "M/d/yy",
"shortTime": "h:mm a"

From those my plan is to either:

1. Create a regex for each pattern and associate it to the type of format.
2. Then when input is parsed, check to see if it matches any of the patterns
3. and then use the locale month array to identify the index of the month entered (if it happens to be the string version)
4. or just use the integer month they entered
5. and parse the date.
6. on the way out (formatting) I could leverage the date $filter.

OR

1. Allow for a mask pattern to be set be the user (matching the formatters from the date filter) that defaults to yyyy-MM-dd
2. Have the input actually mask the users input as they enter it. (This will be a hard one to test in every browser for sure)
3. Parse that input in a similar method to what's above, by creating a regex from the mask defined or simple index-based parsing.
4. Format the rendering with the date filter and the set mask.

... I'm on the fence with each approach. In both cases I'd check to see if the browser already has an implementation of the date input.

Also, there is the consideration of how this would work for the "month" input type and the "datetime" input type.

What are your thoughts?

Other things

I feel like the unit tests around this may need some hardening. I'm not sure most branches of this code have been covered.

[benlesh]

While these inconsistencies are not great, the fact that we can't affect the formatting in chrome anyway makes me think that we could take this PR as is.

So, to be clear from that, do you want me to simply fix the issues you've specified in my current pull request branch and leave it?

Do you want me to branch again and add the other functionality I mentioned in my previous post?

OR... shall I add similar handling to this original PR for <input type="month"/> and <input type="datetime"/>?

(or both I guess)

[benlesh]

I've made what I think are the requested changes.

If this is good to merge with the current functionality, I'd like to go ahead and add the same basic functionality for <input type="datetime"/> and <input type="month"/>, just tying in angular validation. If there are additional, similar inputs, I'm happy to help.

[tbosch]

@Blesh thanks a lot!
We will merge this in in Angular 1.3, as it might be a breaking change.
And yes, it would be great if you could also add support for the other html5 time related input types.

And could you squash your commits into a single commit?

Thanks!
Tobias

[benlesh]

Lol... that commit to utils.js shouldn't have happened. That's actually related to Issue #4595. I have to do that to get grunt package to run. I'll remove that. But I wish I had a better way to handle that.

I will make the requested changes and squash this into a single commit.

[benlesh]

So, I've figured out the fix for the issue in #4595 and closed it. So the utils.js checkins should stop. ;) Haha

[benlesh]

I think I've got it this time.

Please review and let me know if this works. If so, I'll have input types "datetime", "month", "time" and "datetime-local" done in short order. I'm also interested in adding "week" as well.

[timkindberg]

+1

[crissdev]

+1

[ArnauAregall]

+1

[jdhiro]

+1

[gauravmeena0708]

+1

[tagazok]

+1

[bryanrscott]

+1

[vvakame]

👍

[wienand]

+1

[thvd]

+1

[KautskyLozanoV]

+1

[chriswjones]

+1

[Dreamwalker666]

+1

[phillyslick]

+1

[greglockwood]

+1

[isamulenko]

+1

[destegabry]

+1

[g00fy-]

+1

[ThomasWeiser]

+1

[michalkvasnicak]

+1

[tbertenshaw]

+1

[uglow]

+1

[builtbylane]

+1

[itamarro]

+1

[NathanielAJohnson]

+1

[runxc1]

+1

[kbudde]

+1

[tbosch]

Can we close this PR now as you created #5864?

[benlesh]

Yes. This can be closed in favor of #5864