feat(input): allow to define the timezone when parsing and formatting dates

[tbosch]

Allow to define the timezone for parsing dates in input[date], input[time], … as well as in the dateFilter.

Closes #8447.

[tbosch]

@petebacondarwin Could you review this PR and merge it if good?

[petebacondarwin]

@tbosch - is there a reason why some tests use Date.UTC and some +Date.UTC?

[estekhin]

@tbosch

I would say that the L1040 map = { yyyy: 0, MM: 1, dd: 1, HH: 0, mm: 0 }; should instead be map = { yyyy: 1970, MM: 1, dd: 1, HH: 0, mm: 0 }; to be inline with html spec.

The similar correction should be done somewhere near the first change - the base year value should be 1970 instead of 0 which means 1900.

[petebacondarwin]

@estekhin - how come that doesn't fail any of the tests then?

[tbosch]

@petebacondarwin No, the old code contained them for converting a Date into a number and I forgot to remove them, as Date.UTC already returns a number.

[tbosch]

The tests are failing, will look into this on Monday...

[estekhin]

@petebacondarwin base year=1970 is needed for input[time]. What is the policy on that - should I create an issue specific for input[time]?

The idea is that when converting a string value of input[time] into a Date it should be based on 1970-01-01 "date" part as described in http://www.w3.org/TR/html5/forms.html#time-state-(type=time) and http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#time-state-(type=time).
Also input[time] should support seconds, but the current definition in the form of 'time': createDateInputType('time', TIME_REGEXP, createDateParser(TIME_REGEXP, ['HH', 'mm']), 'HH:mm'), stops at minutes.

[tbosch]

I will include it in this PR...

[tbosch]

@petebacondarwin Could you review this?

[petebacondarwin]

This seems OK. I wonder though whether UTC should be the default? Since that is how HTML5 API inputs are supposed to work?

[tbosch]

@petebacondarwin see the comment on the issue that I am about to add :-)