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.

[gpbl]

Hi here, in v9 (react-day-picker@next) we can actually make DayPicker working with UTC dates (GMT). This should solve most of our issue with timezones.

https://daypicker.dev/next/using-daypicker/localization#utc-dates

Please let me know if this solution works for you.

Having UTC, is supporting different timezones still useful? Looking for some use cases.

[ab-pm]

Yes, UTC is not sufficient. In our application, users can pick days (and times) in a calendar that belongs to the displayed item (e.g a venue), not to the current user. As such, the timezone of that venue is neither the current browser timezone nor UTC; and it might not even be the same timezone for all calendars on the same web page. The chosen timestamp may additionally be displayed in the user's timezone elsewhere, but the calendar (day picker) really has its own independent timezone.

Currently this needs to be worked around by ignoring the local timezone of the chosen date and applying the venue timezone to only the year, month and day parts in the onChange handler; and doing the inverse for passing a value. This is cumbersome and errorprone, and breaks down completely when choosing a time of day, where daylight saving time matters.

[gpbl]

@ab-pm, I really can't figure out how to implement timezones in the calendar. Am I missing something or it is actually impossible using native Date objects?

Here is my attempt using a custom Date object constructor. It badly breaks the calendar.

https://codesandbox.io/p/sandbox/stoic-booth-zmgrcy

Why doesn't exist a Date extension such as UTCDate in https://www.npmjs.com/package/@date-fns/utc?

this needs to be worked around by ignoring the local timezone of the chosen date and applying the venue timezone to only the year, month and day parts in the onChange handler

I think this is a fine solution. Have you tried with the toZonedTime() function from date-fns-tz?

Thanks for any help in this direction, @ab-pm .

[ab-pm]

Yes, this is not possible with native Date objects (it would need at Temporal.ZonedDateTime - though once that proposal is implemented, the day picker would probably use a Temporal.PlainDate).

The toZonedTime and fromZonedTime helpers would work, but they're still cumbersome. (Also actually we're using Luxon with Blueprint). As they wrote:

In order to use a date picker in [a custom timezone], the Blueprint components need to be wrapped in converting logic, which means users have to deep-dive into Blueprint and Javascript documentation to figure out what is getting stored where and how to change it manually.

So adding a timezone prop would be greatly appreciated.

[gpbl]

@ab-pm it looks like we can't add support timezone until working with the native Date objects, and that your workaround can't be avoided.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date#date_components_and_time_zones

There are always two ways to interpret a timestamp: as a local time or as a Coordinated Universal Time (UTC), the global standard time defined by the World Time Standard.

If this holds, we should then add some docs about timezones and how to handle them with DayPicker. We could shortcut the workaround in DayPicker itself - but it would require date-fns-tz, while (as in your case) users may want to adopt other libraries.

Sure there's still the option to support https://github.com/dmtrKovalenko/date-io in react-day-picker library, which I think could allow to use Luxon "natively". It would be a big win.