Wrong day

[jonagoldman]

This is taken from the example in https://vcalendar.netlify.com/datepicker.
As you can see the popover says "Sun, Oct 13, 1968" but the calendar shows "Mon, Oct 14, 1968".
This seems to happen only when you go back a few decades, let say to the 60s or 20s...

[nathanreyes]

Interesting, I'm not able to duplicate. Can you provide the following?

Browser:
v-calendar version # (from package.json):

Also, what time zone are you located? I'm wondering if this is a bug when parsing dates into certain time zones.

[jonagoldman]

Browsers:

• Chrome Version 64.0.3282.140 (64-bit)
• Firefox Quantum Version 58.0.1 (64-bit)

OS: Linux (Antergos)
Time Zone: EST (Eastern Standard Time)

I am testing this directly from the example in https://vcalendar.netlify.com/datepicker so I don't have access to the package.json file.
Same result in Chrome and Firefox.

Important: This happens only for specific dates, for example in 2018 it works fine, also in 1884 works fine, but in 1968 it fails.

[nathanreyes]

Do you have vue-devtools installed for Chrome? If so, can you inspect VDatePicker to see what is actually assigned for the value prop?

[jonagoldman]

I have vue-devtools installed, I will try to test it in a few days..

[jgandt]

I have seen a similar issue (I think it's the same issue) and it is related to timezones.

I instantiate a with a set of strings in the dates array:
<v-calendar :attributes="[{ key: 'today', highlight: { backgroundColor: '#ff8866' }, dates: ['2018-02-23'] }]" />

Then in the dateInfo utility it calls setHours(0, 0, 0, 0) which effectively changes the time to the preceding day (EST). I'll see if I can come up with a viable solution.

[nathanreyes]

Ah that is a good catch and may be the culprit. I was basically using setHours to normalize the date value.

[anselmobattisti]

Im facing the same problem, im in Brazil and here is GMT+3 the data saved in mongodb was in UTC and , in order to solve it i add 3 hours, tnkx @nathanreyes for your suggestion

            let dt = new Date(element.date)
            dt.setHours(dt.getHours() + 3)
            this.attrs[0].dates.push(dt)

[jgandt]

PR open. I'm worried about the impact this will have on anyone who already assumes they are using a local date time. However the new Date() syntax always assumes UTC from what I can see so I think it would be a problem for them one way or the other.

[nathanreyes]

@jgandt Thanks for the contribution. Before I accept though, I think there is a separate issue here. Before you were entering the date in the ISO8601 YYYY-MM-DD format, which browsers now implicitly parse in UTC instead of your local timezone (for some strange reason). Case in point, if you were to use slashes instead of dashes, I believe your date should parse correctly.

Let me do some more investigation though.

[jgandt]

Ok cool. How can we solve this? Is there a different code change I should make? Should I be converting all of my Dates to a local DateTime before passing them into the plugin as @anselmobattisti has basically done?

In my testing, I agree that new Date() assumes/parses it into UTC/GMT/Zulu. However I think the new Date() parsing in combination with the setHours is what causes the problem. setHours assumes the time is in local time and then it converts it to UTC time. This behavior of setHours() is extremely surprising to me. I think it's just a bit idiosyncratic javascript cruft.

However, if someone passes in a local date time, unexpected things will still happen.

Thoughts?

[sempixel]

Firefox@58.0.2
v-calendar@0.7.5

Just my two cents. Timezone changes when selecting these days. It also occurs with anothers.

[nathanreyes]

Looking to get this fixed ASAP.

[nathanreyes]

@jgandt I think I will parse date strings using a custom parser as to avoid the UTC conversion problem. Then we can re-assess to see what issues are still existing.

[nathanreyes]

@jgandt Did v0.8.0 fix your parsing issues?

[jgandt]

Yup it did! Thanks so much!

[nathanreyes]

@jonagoldman Ok I know it has been a while. Would just like to confirm to see if you are still experiencing your original bug as of v0.8.0.

[jonagoldman]

@nathanreyes seems fixed now! Thanks!

[nathanreyes]

Thanks. Closing this, hopefully for good.

[Earn717]

"Closing this, hopefully for good."
I'm seeing this behavior again with v2.3.4
dates: ('2022/01/18'), // Jan 18, 2022
dates: ('2022-01-18'), // Jan 17, 2022

[Byloor]

This behavior exists also in 1.0.8.

[waseem786]

@Byloor agree with you.
I am also using v1.0.8 and facing the same issue.
This not happening for all the regions.
As I saw, if the device's local time was US time, I am getting this bug. But I am not getting this issue, if the time was set to Netherlands.
Any way to fix it without upgrading the version?