fix: timezone-matcher-support

[lovebuizel]

What's Changed

• Add matcherWithTimeZone utility for timezone-aware date conversions
• Integrate timezone conversion for disabled, hidden, and custom modifiers
• Ensure consistent date comparisons across different timezones

Problem Description:

When using a timezone that converts today to a different day, the disabled and hidden properties do not update according to the timezone conversion. For example, when today is September 26th in Taipei timezone and I convert to Hawaii timezone (which becomes September 25th), the September 25th date on the DayPicker still remains disabled, but I expect that day should not be disabled.

import React, { useState } from "react";

import { DayPicker, TZDate } from "react-day-picker";

export function TimeZone() {
  const timeZone = "Pacific/Honolulu";
  const [selected, setSelected] = useState<Date | undefined>(
    TZDate.tz(timeZone),
  );
  const now = new Date();
  return (
    <div>
      <h3>{TZDate.tz("Asia/Taipei", now).toString()}</h3>
      <h3>{TZDate.tz(timeZone, now).toString()}</h3>
      <DayPicker
        mode="single"
        timeZone={timeZone}
        selected={selected}
        onSelect={setSelected}
        disabled={{
          before: now,
        }}
        footer={
          selected
            ? selected.toString()
            : `Pick a day to see it is in ${timeZone} time zone.`
        }
      />
    </div>
  );
}

Solution:

Implemented timezone-aware conversion for disabled, hidden, and custom modifiers properties in DayPicker. The fix ensures that all date matchers are properly converted to the specified timezone before being applied, maintaining consistent date comparisons across different timezones.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

[gpbl]

Thanks @lovebuizel for your contribution!

I see the issue: passing a regular Date to the "matchers" wouldn't apply the timezone provided via the prop. A solution here would be to use a timezone-aware date for now, but I agree this behavior is unexpected.

I’ve reviewed the PR, but I’m not sure it’s the right approach. Instead, we should normalize the matchers when used, applying the proper timezone to them. Let me work on this!

[lovebuizel]

Thanks @gpbl for the feedback, I understand! Looking forward to your implementation.

[gpbl]

@lovebuizel Thanks for your patience — I was finally able to make some progress. The hardest part was reproducing the bug. I’ll close this in favor of #2849.