You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 12, 2024. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 12, 2024. It is now read-only.
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:
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.
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
@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.
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.
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 ;)
@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.
@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.
@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 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!
Activity
SekibOmazic commentedon Mar 10, 2014
Could you please post a sample with Plunker or jsFiddle?
veenutanwar commentedon Mar 10, 2014
Please check http://plnkr.co/edit/7NXGsS1RZIBLmcEpwfJ8?p=preview
Thanks
On Mon, Mar 10, 2014 at 5:44 PM, Sekib Omazic notifications@github.comwrote:
SekibOmazic commentedon Mar 10, 2014
Duplicate of #1650 ?
veenutanwar commentedon Mar 10, 2014
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:
Narretz commentedon Mar 10, 2014
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 commentedon Mar 10, 2014
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 commentedon Mar 10, 2014
That's the same then with inpu type=email. Technically correct, but rather unintuitive
caitp commentedon Mar 10, 2014
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 commentedon Mar 10, 2014
@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 commentedon Mar 10, 2014
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.
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 isnew Date(2014, 32, 22)in the case above. Which ends up being2016-09-22or "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 commentedon Mar 10, 2014
@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 commentedon Mar 10, 2014
@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 commentedon Mar 10, 2014
@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 commentedon Mar 10, 2014
@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 commentedon Mar 10, 2014
@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 commentedon Mar 10, 2014
it might be something that could be done with a change to the Regex that controls it... it could get weird though...
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 commentedon Mar 10, 2014
@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!
chore(CHANGELOG.md): add input type date PR as breaking change
tbosch commentedon Mar 13, 2014
Yes, you are right, it was an oversight, sorry. Added it as breaking change to the changelog. Can we close this issue then?
btford commentedon Mar 17, 2014
@tbosch yes
chore(CHANGELOG.md): add input type date PR as breaking change