input[time] Needs default date option.

[SimeonC]

Currently the date value of an input[time] field defaults to 1970, which isn't terribly useful.
Would it be possible to have an optional attribute or ng-model-options value to allow us to set the date of the new time?

Example: Enter in 12:12 am in an input[time] directive, the date is set to 1970-01-01 00:12:00 +1300

Desired Functionality: Enter in 12:12 am in an input[time] with default date set to today, date is set to 2014-10-14 00:12:00 +1300

[btford]

Seems more appropriate to set the "default" from the model-side (in the controller)

[SimeonC]

The problem with that is that the required flags won't work, also it's misleading in terms of UX as the field won't show up blank meaning it's difficult to display that there is no input and they should fill something in. Currently I'm working around this with a custom $parser on the model.

[jimmywarting]

Have also thought about this...
Say you would have this:

// The day baby was born
$scope.babyBorn = new Date("2014-07-20T23:11:44");

<input type="datetime-local" ng-model="babyBorn">
<input type="time" ng-model="babyBorn">

The date may be accurate most of the time but the time isn't. So you would only show the time input.
User clears the time field because it's inaccurate (this will also make the model invalid and won't show the day any longer)

This issue was something that I had in mind when i created #6666 (Change datetime individual) but this wasn't specified in my description. Guessing I didn't know how I wanted it to behave then

My guessing is that there is a variant of desirable behavior for this those making it more suitable for the controller or a custom parser. but doing something about this would perhaps be desirable.

When the model is null or undefined

• Setting a empty time field would make the default day to now
• Setting a empty time field would make the default day to 1970-01-01 (best for working with timestamp, cron jobs & setTimeout)

When the model has a Date Object:

• Clearing the time field would make the model invalid and start from 1970-01-01 when entering new numbers
• Clearing the time field would only set it to midnight and not change the day

and possible some other use cases i forgot about when i created #6666

[jpuffer]

Blindly assigning the date of Jan 1 1970 screws up and time zone offset, especially in zones that use Daylight Savings Time.

In my scenario, the user enters a time and there is helper text to show that time in UTC. It calculates that via the browser's native getTimezoneOffset() method - which is wrong half of the year if Jan 1 is used, because of the DST offset.

A flag to use the current date (instead of Jan 1 1970) for model binding seems to be the most reasonable, so there isn't a need to set a default value in the model. In many cases there ought to be no value in the model until the user inputs text in the form.