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

Wrong date being selected #556

Closed
leads opened this issue Oct 30, 2014 · 16 comments
Closed

Wrong date being selected #556

leads opened this issue Oct 30, 2014 · 16 comments
Milestone

Comments

@leads
Copy link

leads commented Oct 30, 2014

Hi. I raised a bug on an Angular directive using this plugin. However I don't think it's an Angular thing, I think there is a bug with the latest version.

I downloaded the zip from GIthub and ran both index.htm and date.htm.

I think it's an issue when selecting an older date or a date several months in the future.

Select a date in the past, say 7th October 2014, and it selects October 8th (says so in the and highlights the 8th when reopening the calendar). Tested in both Chrome and Firefox on Mac.

Anyone else getting this issue?

@johanhelsing
Copy link

I have the opposite issue, actually. If I select the date programmatically, the wrong date will be highlighted.

var datepicker = $("#datepicker").pickadate('picker');
datepicker.set('select', new Date(2012, 0, 12);
datepicker.render(true);

When I open the datepicker afterwards, 11 January 2012 will be highlighted, instead of 12 January as expected.

EDIT:

It seems pickadate expects a date in utc format. I was able to create a workaround for my issue like this:

function localToUTCDate(date) {
    return date ? new Date(Date.UTC(
        date.getFullYear(),
        date.getMonth(),
        date.getDate()
    )) : undefined;
}
var datepicker = $("#datepicker").pickadate('picker');
datepicker.set('select', localToUTCDate(new Date(2012, 0, 12));
datepicker.render(true);

@ajmueller
Copy link

I am seeing a similar issue that I detailed in #567. "Today" is sometimes highlighting as tomorrow. I wonder if it has to do with time zone calculations as I'm in GMT-0800 and I only noticed this today after 4pm.

@amsul
Copy link
Owner

amsul commented Nov 13, 2014

Yeah, this was a pretty nasty regression introduced in v3.5.4. I've downgraded the gh-pages branch to v3.5.3 - which was the last release before the UTC changes were added.

The UTC problems are no longer an issue in v4 (#446). So instead, I'll be putting my focus on getting that out faster.

If someone wants to tackle UTC in v3, I would definitely accept a PR.

@amsul
Copy link
Owner

amsul commented Nov 13, 2014

At this point, the best solution would be to stick with v3.5.3.

@amsul amsul closed this as completed Nov 13, 2014
@ajmueller
Copy link

Does 3.5.3 have iOS 8 issues? If so, I'd potentially be willing to take a look at the UTC issues in v3 since I'm using this for a major project that will be launching in a few months.

Any idea on the v4 timeline?

@amsul
Copy link
Owner

amsul commented Nov 13, 2014

Yes, I believe so. But I'd like to selectively merge in the commits that resolved those issues without the ones that introduced the UTC bug.

Looking at the changelog now, I think even 3.5.3 has the UTC issue. So 3.5.2 should be the safest choice.

In regards to v4, cannot make any promises, but I would like to have a beta out by the new year.

@marr1977
Copy link

Hi,
regarding #570, it would be nice if the widget is time zone aware. Take the 'max' and 'min' properties for example. It's possible to set a Date object for these attributes in which case we see that pickadate interprets these as being the computer local time zone. But if would be nice to be able to set a different time zone.

Or when you call get('select') on the pickadate widget, you will get an object which, among other things, contains a Date object that corresponds to the selected date in the current time zone.

@Dayjo
Copy link

Dayjo commented Nov 14, 2014

Hi Guys, love the date picker, by far the best one I've found so far.

This issue makes me sad, just discovered it in my implementation.

Is the only way to fix this at the moment using 3.5.2?

Thanks for your hard work, I hope I can contribute somehow (maybe not UTC handling just yet ;))

@Dayjo
Copy link

Dayjo commented Nov 19, 2014

Also, @amsul is this issue really closed? I think it's worth keeping it open until there's a solution so that it stops being raised?

@amsul
Copy link
Owner

amsul commented Dec 7, 2014

I’ve pushed the fix to the master branch: https://github.com/amsul/pickadate.js/tree/master

Can someone please verify it works for them as well?

@ajmueller
Copy link

I have a reminder to test this at 4pm my time today since, as I noted above, this appears to be timezone dependent. I'll let you know the outcome.

@ajmueller
Copy link

Validated that the issue is gone on master. I suppose next time I could just manually update my system clock instead of waiting...oh well. This gave me a simple thing to do at the end of my day.

Thanks for the fix. I'm using your plugin in a very large project and the functionality of having a date picker is vital.

@luisrudge
Copy link

any ETA on the next release?

@amsul
Copy link
Owner

amsul commented Dec 12, 2014

Hoping to have it out by next week. Just need to make sure all the iOS8 issues have been resolved ( #523 ). People with iPhones, I'd appreciate any verification :)

@cmwelsh
Copy link

cmwelsh commented Jan 7, 2015

This makes the current version totally useless... push out a new release... 👍

@amsul
Copy link
Owner

amsul commented Jan 11, 2015

This is fixed on master - feel free to point to there with Bower (or whatever your tool of choice).

3.5.5 will be tagged when the remaining issues are resolved: https://github.com/amsul/pickadate.js/milestones/3.5.5

Cheers.

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

No branches or pull requests

8 participants