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.

[gpbl]

If my understanding of how DayPicker works is correct (I've read through some of the source code but not much), then the only thing it really has to do differently is to use timezone-delineated dates for its internal mechanics (display month, selected date, disabled dates, etc).

The dates to display are calculated in this loop:

https://github.com/gpbl/react-day-picker/blob/main/src/helpers/getDates.ts#L51

• Without extra options, it is an array from the first to the last day of the displayed month. Days are dates that start always at midnight.
• The dates are then grouped per week of the year and displayed in the grid.

When passing a disabled date, it checks if it the same day as the one displayed and disable its button.

I am failing to see what DayPicker should do instead, when using a timezone prop 🤔

So, with the example of the selected date, when the user clicks on a new day, instead of returning that day at midnight in the user's timezone, it would return that date at midnight in the configured timezone.

The onSelect / onDayClick callbacks return the date the user has clicked. To know which date it is in another timezone, we can use date-fns-tz. Similarly, we could pass "converted" dates to the disabled prop. Doesn't this work already?

(Sorry - not at my laptop to write some sample code)

[millansingh]

For the example you provided, I think when creating new Dates (line 56/64), you'd need to create them in the provided timezone. What I'm saying is the Dates that the DayPicker operates with internally should all be in the provided timezone. That way, when you interact with the calendar, you know that all the dates you get out of it will be in the timezone you want them to be in so that you don't have to do any translation back and forth between the User's timezone and the one you want to operate in.

[gpbl]

Hi @millansingh thanks again for the follow-up.

So I've looked how other languages implements "timezoned" date picker: SwiftUI, for example, is in the same condition: only local times or utc. The timezone is used only when "formatting" dates.
I've found interesting this comment on Stack Overflow:

You cannot "get a time zone" from a date picker. You can just get a date. The date will be independent on the current time zone of the device. Perhaps you think you have a different date, but actually, there is no such thing as a "UTC date" or "EST date". Instead, there is only one date, and you use date formatters to display them for various time zones.

To me, the "timezone" is so far a non-issue.

We could provide an example app that works with timezones. Here I am out of idea. We need some specs and unit tests and see where is the blocker part. So far it seems just about formatting dates...

[francescotau]

Hi @gpbl, there are edge cases where it is necessary to use the calendar with a specific timezone different from the browser timezone.

Suppose I live in X (+00:00), but for work I am in Y (+10:00). If at X it is 14:00 then at Y it is 00:00 of the next day. So if I open a web app that resides in X, I expect to find a calendar that works respecting the timezone of X.

[gpbl]

Suppose I live in X (+00:00), but for work I am in Y (+10:00). If at X it is 14:00 then at Y it is 00:00 of the next day. So if I open a web app that resides in X, I expect to find a calendar that works respecting the timezone of X.

@francescotau think that a user select a day. They don't make assumptions about the time. It is like the selected date is returned as 2024-07-10. They are a native Date object just for convenience. Then, it's up to you to store it with the time you want.

You could for example work with Luxon or other libraries if you need full timezone support.

[gpbl]

It looks like with the new date-fns@4 and the @date-fns/tz package, we can finally add a timeZone prop (see PR#2467).

We can publish this prop with an experimental flag to see how it goes. I'd love to know the feedback from participants here 🙏🏽.

[gpbl]

The new experimental timeZone prop has been added to v9.1.1 🎉

import { DayPicker, TZDate } from 'react-day-picker';
<DayPicker 
    timeZone="Europe/Athens"  // set the time zone
    disabled={TZDate.tz("Europe/Athens")}  // make sure you use `TZDate` to initialize dates
/> 

Please open issues or another discussion if you would like to provide feedbacks. Thanks!