input type date problem

[veenutanwar]

i try 1.3 beta n found when using input type "date" ng-module not working...

[SekibOmazic]

Could you please post a sample with Plunker or jsFiddle?

[veenutanwar]

Please check http://plnkr.co/edit/7NXGsS1RZIBLmcEpwfJ8?p=preview

Thanks

On Mon, Mar 10, 2014 at 5:44 PM, Sekib Omazic notifications@github.comwrote:

Could you please post a sample with Plunker or jsFiddle?

Reply to this email directly or view it on GitHubhttps://github.com//issues/6630#issuecomment-37175816
.

[SekibOmazic]

Duplicate of #1650 ?

[veenutanwar]

Duplicate of #1650 ????
It is on 1.2
with 1.2.13 it is working fine
but I am using 1.3
On 10 Mar 2014 18:26, "Sekib Omazic" notifications@github.com wrote:

Duplicate of #1650 #1650 ?

Reply to this email directly or view it on GitHubhttps://github.com//issues/6630#issuecomment-37178776
.

[Narretz]

1.3 introduced support for input type=date via directive. the model for a input type=date must now always be a Date() object:

http://docs.angularjs.org/api/ng/input/input%5Bdate%5D

This is actually a breaking change ...

What's also weird is that you can enter nonsense dates, and this gets propagated to the modek:

http://docs.angularjs.org/api/ng/input/input%5Bdate%5D

enter something like 2014-33-22, and see what happens

[caitp]

enter something like 2014-33-22, and see what happens

This is correct according to the Date specification in javascript, IIRC --- EG if you say "the 14th month of this year", the engine should translate that into the second month of next year.

[Narretz]

That's the same then with inpu type=email. Technically correct, but rather unintuitive

[caitp]

I think it's probably pretty useful, eg if you know something is going to be 14 weeks from now, and you don't want to figure out exactly what that will translate to on a real calendar, you can just do the simple arithmetic in your head and the engine will take care of it for you.

I don't really see that as problematic, but maybe @Blesh or @tbosch have something to say about it

[SekibOmazic]

@caitp If you now something is going to be 14 weeks from now then something like "new Date().plusWeeks(14)" would be intuitive. This is what JodaTime library does in Java.

[benlesh]

1.3 introduced support for input type=date via directive. the model for a input type=date must now always be a Date() object:

The original implementation from my PR allowed for either a Date or an ISO String, but would always put a Date object back to the model. But it was decided that it wasn't intuitive to do this. There is an argument for "string in string out" I suppose. But that could get crazy if the desire was to support many different date input formats (e.g. 12/23/2014 or Dec 23, 2014) and then output to the same. It's doable, especially with the date service I'm working on... but it might be a lot of extra code into the code base for not a lot of benefit.

enter something like 2014-33-22, and see what happens

This is because in some browsers Date.parse() won't properly parse an ISO date string. This forced me to manually parse the string. During that process I didn't add any extra code in to validate dates, and instead just defaulted to the behavior of the Date object. Which is new Date(2014, 32, 22) in the case above. Which ends up being 2016-09-22 or "33 months and 22 days after January 1, 2014". I'd say add an issue with some compelling logic as to why it's an issue, then submit a PR that solves it. I'm not saying it "isn't" an issue, it may be for some people, so if there's a popular outcry for the fix I'm sure the Angular team will give it due consideration.

I hope this information helps.

[caitp]

If you now something is going to be 14 weeks from now then something like "new Date().plusWeeks(14)" would be intuitive. This is what JodaTime library does in Java.

@SekibOmazic, you can't really do this from a form control, that doesn't make any sense. it would be a terrible UX to force users to go into the script console and do this manually ;)

[Narretz]

@Blesh I think you should retro-actively put this change as breaking into the changelog, since it actually breaks any date field that uses ng-model without a Date() object. I guess in most cases the input is some sort of datepicker anyway, but in cases where people use the blank date field, it's very probable it doesn't use Date() in the model.

[benlesh]

@Narretz - I'm actually a little shocked it wasn't listed as a breaking change, because I know it was discussed to be such, which is one of a few reasons why it was put in 1.3 rather than 1.2. ... But I'm not a team member, so I'll leave the updating of the changelog to them.

[SekibOmazic]

@caitp Entering something like '2014-33-22' just doesn't feel right. The JavaScript would then "guess" what I really mean? The answer would be "33 months and 22 days after January 1, 2014". I don't know if this is allowed: '2014--33--22' ("33 months and 22 days before January 1, 2014")?
To shorten the story: javascript date handling is just weird to me (Java background). But c'est la vie.

@Blesh Nice work.

[caitp]

@SekibOmazic you probably want to take that up with Brendan Eich or something, but yeah that's what the date object will do, and I think this is ok

[benlesh]

it might be something that could be done with a change to the Regex that controls it... it could get weird though...

var DATE_REGEXP = /^(\d{4})-(((01|03|05|07|08|10|12)-(0[1-9]|[12][0-9]|3[01]))|((04|06|09|11)-(0[1-9]|[12][0-9]|30))|((02)-(0[1-9]|[12][0-9])))$/;

I pulled this out of my butt, so I make no guarantees that it will work. ... and that's not going to account for leap years...

(I'm kidding about this idea)

[Narretz]

@Blesh The changelog.js script seems to be able to parse Breaking changes if they are put in the commit message. But I'm not blaming you, it was simply an oversight. Just can't hurt to put it in for those that upgrade from 1.2 to fresh 1.3 builds. You can write a pull request that changes the changelog.md (I'd do it myself, but since you wrote the commit ...) In any case, thanks for your work!

[tbosch]

Yes, you are right, it was an oversight, sorry. Added it as breaking change to the changelog. Can we close this issue then?

[btford]

@tbosch yes