Issue

Today availability ends at 5pm PST even if availability extends beyond 5pm. This is likely because PST is -7 UTC, so when the application is creating dates, the remaining slots are being shunted to the following day.

Details

This issue ties in with #14 , it's probably the same bug.

Steps to reproduce

• Edit ending hours in config to greater than current set value of 17
• View appointments later than current date on localhost or online

const DEFAULT_WORKDAY = [
  {
    start: {
      hour: 9,
    },
    end: {
      hour: 23, // <-- Changed 17 to 23
    },
  },
]

Vercel Branch Deploy

• Link to Github.com branch of deploy preview

Screenshots

View Screenshot

Expected Behavior

Loading the base website / should direct the user to the first available day of appointments, eg Friday

Observed Behavior

During certain time windows the application loads / and directs the user to the following day, eg Saturday

Details

This is likely because the useEffect hook isn't consdering timezone when offering suggestions of date.

// index.ts
  useEffect(() => {
    if (!selectedDate && slots.length > 0) {
      dispatch({
        type: "SET_SELECTED_DATE",
        payload: Day.dayFromDate(slots[0].start), // <-- Doesn't take into account frontend timezone
      })
    }
  }, [])

Screenshots

View Screenshots

Issue

When increasing DEFAULT_WORKDAY hours from 17 to 23, potential appointment slots in future days sort out of order in regard to Los Angeles timezone (hasn't been tested with other timezones at time of writing).

Steps to reproduce

• Edit ending hours in config to greater than current set value of 17
• View appointments later than current date on localhost or online

const DEFAULT_WORKDAY = [
  {
    start: {
      hour: 9,
    },
    end: {
      hour: 23, // <-- Changed 17 to 23
    },
  },
]

Vercel Branch Deploy

• Link to Github.com branch of deploy preview

Screenshots

View Screenshot

Love the project! I had a similar urge to make a simple white-labeled scheduler. Happy this is already out there!

One small improvement from a UX perspective is that the browser has timezone available via Intl.DateTimeFormat().resolvedOptions().timeZone.

Wrapping a setter in a UseEffect, e.g.:

import { useEffect } from 'react';
import { useProvider } from "@/context/AvailabilityContext"
import getTimezoneData from "@/lib/timezones"

const { groupLookupMap, timeZoneMap } = getTimezoneData()

export default function TimezonePicker() {
  const {
    state: { timeZone },
    dispatch,
  } = useProvider()

  useEffect(() => {
    // Set the timezone from the browser when the component mounts
    const browserTimezone = Intl.DateTimeFormat().resolvedOptions().timeZone;
    dispatch({
      type: "SET_TIMEZONE",
      payload: browserTimezone,
    });
  }, [dispatch]);

  // ... rest of TimezonePicker.ts

... automatically selects the user's browser's timezone without them having to go fish for it.

Thank you for this and kudos!

Expected Behavior

Available slots for TODAY extending from NOW until 11PM PST

Observed Behavior

No more available openings for today despite those hours being open as defined by DEFAULT_WORKDAY

Screenshot

Has anyone gotten an error where they were unable to use the refresh token to retrieve a new access token? I'm getting this error

Error: Couldn't get access token: {
"error": "unauthorized_client",
"error_description": "Unauthorized"
}
even though I got the refresh token as instructed in the environment setup.

Overview

Same timezone bug as before, differnt part of the app (Now in days of calendar rendering). Forcing timezone to UTC resolves.

Screenshots

screenshots

Before

After -- with fix

This is so good self-scheduling project! Thanks for sharing 🙏

Is it possible to extend this so that it can handle a few different users/calendars? Maybe a dropdown like Timezone but with all users added and when you select a user the calendar is based on that users availability? Do you know if this is difficult to integrate and solve?

Hi, I've noticed if changing the owner timezone to another country i.e. something like Australia, (in config.ts -> OWNER_TIMEZONE), I get an error:
error lib\availability\helpers.ts (68:20) @ toLocaleTimeString

• error Error [RangeError]: Value longGeneric out of range for Date.prototype.toLocaleTimeString options property timeZoneName
  at Date.toLocaleTimeString ()

  I've noticed this problem goes away by removing the timezonename: "longGeneric" clause in request.ts interval to human string fx ->
  '''
  function intervalToHumanString({
  start,
  end,
  timeZone,
  }: DateTimeIntervalWithTimezone): string {
  return ${formatLocalDate(start, { month: "long", day: "numeric", hour: "numeric", minute: "numeric", weekday: "long", timeZone, })} – ${formatLocalTime(end, { hour: "numeric", minute: "numeric", timeZone, timeZoneName: "longGeneric", })}
  }
  '''
  when removing timezonename: "longGeneric" i no longer have this problem i.e.
  '''
  function intervalToHumanString({
  start,
  end,
  timeZone,
  }: DateTimeIntervalWithTimezone): string {
  return `${formatLocalDate(start, {
  month: "long",
  day: "numeric",
  hour: "numeric",
  minute: "numeric",
  weekday: "long",
  timeZone,
  })} – ${formatLocalTime(end, {
  hour: "numeric",
  minute: "numeric",
  timeZone,

  })}`
  }
  '''