Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open Pickadate with a default value select bad month #154

Closed
benjamincanac opened this issue Jun 21, 2013 · 6 comments
Closed

Open Pickadate with a default value select bad month #154

benjamincanac opened this issue Jun 21, 2013 · 6 comments

Comments

@benjamincanac
Copy link

I have a problem with pickadate.

In my view, there is an input with a default value in good format.

I load pickadate on it when the DOM is ready.

When I click on the input, it will show me the calendar as expected, but the month selected is the month + 1 the default value of the input.

For example you have in your input : "21-06-2013", you click on it and the month that will be selected on the calendar is July. No idea why.

This problem is only when the input is pre-set non when it's empty.

Thanks.

@annez
Copy link

annez commented Jun 22, 2013

The culprit for this, is this line:

return [ parsingObject.yyyy || parsingObject.yy, +( parsingObject.mm || parsingObject.m ) - ( options.data ?  1 : 0 ), parsingObject.dd || parsingObject.d ]

Line 451

It seems if you set a data-value on the input, it will add the additional month on for you, but otherwise it miscalculates the months if they are already in correct format in the value attribute.

This is specifically annoying for Rails, where if you have a datetime field, the value format is always correct, so it should always be nudged 1 to the right.

I'm not sure why this decision was made, so hopefully amsul can give a bit more insight.

EDIT - This code is due to translations, so the values don't get screwed up. Fair enough

@amsul
Copy link
Owner

amsul commented Jun 22, 2013

Yeah @annez is right.. It was for translations but there was an oversight with the basic behavior of using “mm” or “m” within the input value.

I just pushed a fix to the edge branch that fixes this issue..

@amsul amsul closed this as completed in 1bc6b73 Jun 22, 2013
@benjamincanac
Copy link
Author

Thanks for the fast fix, it's perfectly working now :).

@howlermonkey
Copy link

@amsul - I have the same problem on 3.2.1 as was recognised above. Has the fix been carried forward? It only occurs when using default values. Can send link example if required. Notice code listed above is still included in latest version - now line 469 though.

@Ymx1ZQ
Copy link

Ymx1ZQ commented Mar 28, 2014

same problem as howlermonkey in version 3.4.0
:(

@amsul
Copy link
Owner

amsul commented Apr 2, 2014

@Blue1987 there's a PR with the fix here: #358. Going to be merged into 3.4.1 eventually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants