nathanreyes / v-calendar

An elegant calendar and datepicker plugin for Vue.
https://vcalendar.io
MIT License
4.39k stars 859 forks source link

day off by 1 #1204

Open dbaldw10 opened 2 years ago

dbaldw10 commented 2 years ago

So my events are rendering on the calender just off by one day. and I cannot figure it out for the life of me, in vue3. ugh. so if the event should be on the 15th its on the 14th.

dbaldw10 commented 2 years ago

image

natenatters commented 1 year ago

I am experiencing the same issue! Did you resolve it?

Im hoping I dont have to remove 1 day from it every time!

natenatters commented 1 year ago

The issue turned out to be I was using the timezone prop on the date-picker. The timezone was set to Europe/London, but I am actually in Italy. So, I just removed the prop for now, as we arent using times.

zavvdev commented 1 year ago

Have the same issue. I set timezone to America/New_York in my browser as well as for calendar

Screenshot 2023-07-21 at 12 57 11 PM

r component.

Screenshot 2023-07-21 at 12 57 32 PM

Days are still shifted even if I remove timezone. But I don't need to remove it and it seems like timezone doesn't work at all... @nathanreyes

<vc-date-picker
      :value="date"
      @input="change"         
      mode="date"       
      color="blue"
      :available-dates="dates"
      :model-config="modelConfig"
      :select-attribute="selectAttribute"
      timezone="America/New_York"
    />

 data() {
    return {
      modelConfig: {
        type: 'string',
        mask: 'YYYY-MM-DD',
      },
      date: "2023-07-20",
      dates: ["2023-07-20", "2023-07-21", "2023-07-22"],
      selectAttribute: {
        dot: true,
      },
    }
  },

"v-calendar": "3.0.3", "vue": "^2.6.12",

iKlsR commented 1 year ago

Had this issue for 2 years, was adding a datepicker to a new project and checked to see if this issue was fixed, still persistent but for anyone who likes this library and wants to keep using it I workaround it using this helper method

import { format } from 'date-fns'

...

formatDate(dateString) {
    const date = new Date(dateString + 'T00:00:00')
    return format(date, 'MMMM d, yyyy')
},
whaaaley commented 10 months ago

Yeah same here this is still an issue

filoromz commented 10 months ago

the issue i experienced seems to be similar. my issue happens when:

the main cause of it is by default v-calendar@3.1.2 uses midnight (12:00am) for the time portion when selecting a given date for a timezone. It strips away the time that has elapsed since midnight of the selected timezone.

it becomes problematic when you interact with the date picker at a time when the browser timezone and selected timezone fall into 2 different days. For example if the current time is 12:01AM, January 1 2024 (UTC)

when you select “January 1” on the date picker in Sydney selected timezone, it auto-selects as 12:00 AM, January 1, 2024 in that timezone which means what gets actually selected in browser timezone is

i managed to fix this by manually updating the modelValue (v-model) before we pass it back to v-date-picker to add the missing time since midnight of the given timezone:

/**
 * Returns the number of milliseconds since midnight in a given timezone
 */
const getMsSinceMidnight = (tz?: string): number => {
  // coerce empty string, null, undefined to undefined
  const validTimeZone = !tz ? undefined : tz
  const tzString = new Date().toLocaleString('en-US', { timeZone: validTimeZone })
  const tzDate = new Date(tzString) // in local time
  const diff = tzDate.getTime() - tzDate.setHours(0, 0, 0, 0)
  return diff
}

return modelValue.getTime() + getMsSinceMidnight(timezone)

i also observed that using timezone prop with a string modelModifier may cause some issues too. Since I don't have control over what v-calendar does underneath when it comes to time conversions, I opted to always pass in UTC timezone whenever I want to use the string modelModifier. That way, it guarantees that all internal calculations are done in UTC, the string modelValue itself returns as a compliant ISO-8601 format. Once I have the ISO-8601 formatted string, I can do additional formatting to this modelValue to my liking (e.g. just keeping the YYYY-MM-DD)