support for input type date and time - #1650

[felixebert]

Added support for the new html5 input types date and time. As this is my first contribution to angular.js, i basically copied and then modified the code for input type number instead of refactoring the input.js for a more generic handling of the different input types.

related issues: #1650 #757

[petebacondarwin]

• Contributor signed CLA now or in the past (if you just signed, leave a comment here with your real name for cross reference)
• Feature improves existing core functionality
• API is compatible with existing Angular apis and relevant standards (if applicable)
• PR doesn't contain a breaking change
• PR contains unit tests
• PR contains e2e tests (if suitable)
• PR contains documentation update
• PR passes all tests on Travis (sanity)
• PR passes all tests on ci.angularjs.org (cross-browser compatibility)
• PR is rebased against recent master
• PR is squashed into one commit per logical change
• PR's commit messages are descriptive and allows us to autogenerate release notes (required commit message format)
• All changes requested in review have been implemented

[petebacondarwin]

Hi @felixebert
Thanks for this contribution. I have added a checklist of things you should go over before this PR can be included.

I haven't actually tried this yet, but I am wondering how it works out with browsers that don't support date and time inputs and also what features of HTML5 date time are stable across browsers and supported/unsupported here?

[felixebert]

Hi @petebacondarwin

Recent versions of Chrome, Safari, Opera and - more important - Safari on iOS and Chrome on Android support date and time inputs. The exact feature set varies. As for example, the displayed date isn't localized on opera and the current stable version of chrome on android (which can be very annoying, because there is no way to change this behaviour). Another example are the min / max attributes - Chrome and Opera support them, Safari doesn't support them. Still, the usage of the native date picker can have advantages (especially on modern iOS and Android devices) - you have a native look & feel, no positioning issues and most likely a better performance.

As the internal value of a date input is always in the format YYYY-MM-DD (as specified by w3c), browsers without support for date inputs would just display the current value in this format. The implementation in this PR doesn't contain a special support for those browsers at the moment - it just supports input values in the format YYYY-MM-DD.

As I think over my pull request, this is a bit problematic. The typical use case seems for me a developer that wants to use the native date and time picker on iOS 5 and Android 4 and a custom javascript datepicker for desktop browser / browsers that don't support these input types yet. Since the implementation in this pull request does require an input value in the format YYYY-MM-DD, the developer has to manually switch the input type to 'text' to be able to use another format with a custom javascript datepicker.

Therefore I close this pull request for now, since it isn't useful for the typical use case.
What do you think about extending this implementation with support for individual date formats (e.g. by adding a format parameter to the directive) and always return a date object to the controller? Seems to be a bit complex and time-consuming to implement, but would be surely comfortable to use

A quick option would be to handle unknown input types just like input type text (without any additional type-specific validation like in this pull request). This is better than to prohibit the usage of this input types at all (like now), but is surely not very comfortable.