Support for different timezones

[mauriciosoares]

Is your feature request related to a problem? Please describe.
This is a feature that was requested a while back here: #1149, a few devs are having problems when their apps deals with different timezones

Describe the solution you'd like
We could use a prop like timezone where we can set what's the timezone that the calendar should consider for setting the date.

Today if we set a date that has an UTC offset of 0, let's say Thu, 27 Jan 2022 00:00:00 GMT-0000, if the user's browser timezone is set to something with a negative UTC offset (like BRT which is -3), then when opening the date picker, the picker will have selected 26 of January, because Thu, 27 Jan 2022 00:00:00 GMT-0000 in BRT is Wed Jan 26 2022 21:00:00 GMT-0300.

So the picker, if configured, shouldn't consider the browsers current timezone, it should consider the one configured as a prop.

[gpbl]

Hey thanks for opening the issue. Please forget the old one because we've lost the thread there...

if we set a date that has an UTC offset of 0, let's say Thu, 27 Jan 2022 00:00:00 GMT-0000
if the user's browser timezone is set to something with a negative UTC offset (like BRT which is -3)

Wouldn't be easier to set the date to the user's timezone instead? Why setting a date using another offset?

Help us understand with an example using the beta: https://codesandbox.io/s/ivs35 thanks.

[mauriciosoares]

@gpbl That's just a feature that our app supports, the user can configure the way the dates are displayed in the entire app based on the timezone they picked

So we can't just show the date in their own timezone. For example if one of our clients have offices in Japan and in the US, that client has an option to show the date for everyone in UTC.

[gpbl]

Sorry, I fixed the codebox link.

Say we do support this feature, maybe with a timezone prop, how would the behavior of this DayPicker change? https://codesandbox.io/s/ivs35

Timezones are still confusing to me :) I understand that date-fns is not supporting timezones but date-fns-tz does. I'd prefer to not add a new dependency to this package so I'm trying to understand if this can be done from the consumer side.

[mauriciosoares]

Hey @gpbl, sorry for the delay. Here's an example of what I'm talking about:

https://codesandbox.io/s/sandpack-project-forked-dd9bh

So I'm using in the component a date that's in UTC 2022-02-10 00:00:00+00, and my browser's locale is in BRT (which is -3), if you check the screenshot below, the date I'm using on the component is 10th of february, but the component show's 9 of february as selected, because after converting that date to BRT, it converts it to 2022-02-09 21:00

That happens because the DayPicker converts the date automatically to the user's browser timezone out of the box... so my idea was that we had a prop to force the DayPicker to use another timezone other than the user's timezone, like:

<DayPicker timezone="UTC" />

[gpbl]

@mauriciosoares let me understand the need to initialize the date by string and not by new Date(year, month, day). I agree the result is not what is expected, but it is because it is not expected the date constructor to convert to UTC.

I think I understand the requirement, I wonder for now if there's an acceptable workaround without changing DayPicker, that we could add to the documentation.

[mauriciosoares]

let me understand the need to initialize the date by string and not by new Date(year, month, day)

The Date constructor accepts strings as initializers so we should be able to use that... Also I don't have access to the year/month/day as separate variables, specially since this value comes from an API as a full string.

[tjfred35]

We discovered parseISO from date-fns to solve this problem

[mauriciosoares]

So is there a plan to include that in the library in a future release? If so, do you think there's a way to workaround that for now?

[gpbl]

The Date constructor accepts strings as initializers so we should be able to use that...

Here is advised we should not: https://developer.mozilla.org/enUS/docs/Web/JavaScript/Reference/Global_Objects/Date/parse

It is not recommended to use Date.parse as until ES5, parsing of strings was entirely implementation dependent. There are still many differences in how different hosts parse date strings, therefore date strings should be manually parsed (a library can help if many different formats are to be accommodated).

I think the suggestion by @tjfred35 is to use parseISO to initialize dates from strings instead.

I see this as a non-issue, or an improvement to the developer experience. Sure we should add a note to the documentation, maybe even some dev-only alert when passing dates with a different timezone.

I wonder however how does other libraries like react-datepicker or airbnb's deal with this case?

[gpbl]

I wonder however how does other libraries like react-datepicker or airbnb's deal with this case?

It seems a common request, but the solution proposed is always to not pass UTC dates: Hacker0x01/react-datepicker#1787

The date-fns-tz package may help creating a wrapper over DayPicker. For example, we could create a new react-day-picker-tz package that depends from that package and adds support to timezones. Also, date-fns-tz uses browser's native Intl API, so it does not add so much data to the final bundle.

It would be nice if somebody familiar with the react-day-picker source code to explore the alternatives here, the amount of work, etc.

[gpbl]

This branch https://github.com/gpbl/react-day-picker/tree/utc has added a timezone: string to the DayPicker props. From here I invite other devs to propose a solution in a PR, as I've no time for working on this ATM.

Also related discussion: #1149

[BlueBird67]

I have also the same issue, very problematic. Could we have the choice to use TZ or not?

[kdurek]

Seems like this did a trick for me:

export function correctUTC(date: Date) {
  return new Date(date.getTime() - date.getTimezoneOffset() * 60000);
}

Just use it onSelect

<DayPicker
  mode="single"
  selected={field.value}
  onSelect={(selectDate) =>
    field.onChange(correctUTC(selectDate))
  }
/>

Doesn't matter what timezone I set, I get the same datetime

[apudiu]

When working with Time zone, using JS Date is a poor idea. I think there should be an option to swap date-fns with Luxon which has fantastic TZ support

[gpbl]

Should note here the recent release of https://github.com/date-fns/utc. Could this library help with supporting UTC in Day Picker?

[melvinwallerjr]

I've been recently trying to upgrade from v7 and experiencing a lot of the same issues. Handling different time zones and selected/picked dates being off by a day.

One of the things I ended up having to do is convert all dates to a UTC standard. The standard date string would be yyyy-MM-dd and the user input date would be converted to this format and then converted to UTC. I used a function to attach the current time and timezone data before providing it to the day picker.

/**
 * Converts a string to a Date object with the current local timestamp.
 * @param date - string
 * @param dateFormat - format of date string, default = 'yyyy-MM-dd'
 * @returns UTCDate
 */
export const getTimeStamp = (date: string, dateFormat = 'yyyy-MM-dd'): Date => {
  const now = new Date();
  const day = parse(date, dateFormat, now);
  return new Date(
    day.getUTCFullYear(),
    day.getUTCMonth(),
    day.getUTCDate(),
    now.getUTCHours() - now.getTimezoneOffset() / 60,
    now.getUTCMinutes()
  );
};

This will likely need to change as parse from [email protected] was flagged as a [Critical] XPath injection vulnerability.

I'd really like to see these issues addressed in v9 of day picker.