Timezone support

[Nevon]

Currently it looks like the calendar is hard-coded to Europe/London. This should likely be set to the timezone of the calendar, or perhaps a setting on the user.

Not sure what the experience from the user perspective is - if it should show in the timezone of the calendar or if it should be translated into the timezone of the user.

[surjithctly]

Agreed. without showing the Timezone on the client side, it will be really confusing. Great if the times are automatically converted to user timezone and mention it visibly.

[abrambailey]

Yeah, this won't work for me either without it.

[emrysal]

#8

Currently this translates it without telling the user the person they are booking is in a different timezone, so this would be a future addition. Current behaviour shows the bookable slots as it is known by the user, so for example a meeting slot booked for 3pm agent time UTC+0600 would show up as a 10am slot for the booker in the UK.

[abrambailey]

Interesting, how do you know the user's TZ? What if they are traveling?

[surjithctly]

@abrambailey Usually it's based on Geo-location along with an option to modify it.

I prefer something like this:

[Nevon]

You can get the offset between the current user and UTC by doing new Date().getTimezoneOffset(). I'm in CET, which is currently two hours ahead of UTC, which means that it returns -120.

[abrambailey]

I would place the time zone drop down here, as people may miss it on the first page:

[50bbx]

Hey guys,

I implemented this feature, both for the owner of the calendar and for the user choosing a slot.

No dropdown yet (just getting default timezone), but I will create a PR tomorrow.

[50bbx]

Basic time zone support PR: https://github.com/calendso/calendso/pull/28

[baileypumfleet]

Okay, so we have the basic timezone support PR merged in and everything, so let's discuss next steps. I know we would still need to add the timezone label or dropdown on the booking page, for instance.

[surjithctly]

when will this available? I don't see it in the live demo.

[baileypumfleet]

Just to update you all, as part of this, I've added a new field on the booking screen's left column which shows the guessed timezone. If you click it, there's a dropdown to switch between 12 and 24 hours, but that's where the timezone selection should also go.

[surjithctly]

Perfect.

[50bbx]

@baileypumfleet Did you make a pull request?

I have the code ready locally to switch between timezones

[baileypumfleet]

@50bbx No, I directly committed it

[Soneji]

Hi all, I just thought I'd drop by and mention a test case that often causes a problem with timezones, and has also caused a problem for Easy Appointments

The test case is for countries/timezones that change for daylight saving time. It can often result in entire calendars being out of sync by 1 hour and also possibly one week with correct timings, and the week after daylight saving time starts being 1 hour out of sync

Thanks in advance

[baileypumfleet]

@50bbx Is your code for switching between the timezones ready for a PR? Super excited to get this added in :)

[50bbx]

I saw that there were some changes on the timezone component selector, here We need to address those and understand how we are going to manage the timezone selector.

I need to add that component to the book an appointment page.

When we settle things down on that side I will extract the timezone selector in a separate file and make the PR.

[harad]

Hi all, I just thought I'd drop by and mention a test case that often causes a problem with timezones, and has also caused a problem for Easy Appointments

The test case is for countries/timezones that change for daylight saving time. It can often result in entire calendars being out of sync by 1 hour and also possibly one week with correct timings, and the week after daylight saving time starts being 1 hour out of sync

We could go think about using Coordinated Universal Time, like Google Calendar does, to not run into the issue of daylight saving.

https://en.wikipedia.org/wiki/Coordinated_Universal_Time

[emrysal]

Hey @50bbx - This was a small amend not to change any logic, but whilst condensing the options I was thinking that it would make sense to extract the timezone logic into a seperate component as well, to implement extra features. For example so we can also show the GMT+X difference as part of the label, then include this component similarly on the appointment section.

@harad1 Internally, @50bbx and I used UTC; you can see this for example by the call to /book (which is all done in UTC). UTC works with all calendars regardless of the timezone. Even though this works theoretically; it needs double checking. In addition, the reason there is some options in the dropdown selector that seem awfully specific (Like "Europe/Bucharest") this has the reason that they handle DST differently; Bucharest for example enters and leaves DST one hour later (at 3am) than the rest of Europe (mostly 2am).

[50bbx]

Ok, I tried to add the TimeZone selector used here. But now it is really hard to use it with dayjs.tz.guess().

In the pages/[user]/[type].tsx file these are the critical changes:

export default function Type(props) {
  //...
  const [selectedTimeZone, setSelectedTimeZone] = useState(dayjs.tz.guess());
  //...
  return (
    <TimezoneSelect id="timeZone" value={selectedTimeZone} onChange={setSelectedTimeZone} className="shadow-sm focus:ring-blue-500 focus:border-blue-500 mt-1 block w-full sm:text-sm border-gray-300 rounded-md" />
  )
}

In my case dayjs.tz.guess() returns Europe/Rome, but react-timezone-select aggregates timezones and Europe/Rome is not present, only Europe/Amsterdam and Europe/Brussels are.

Basically, setting value this way, defaulting to the dayjs.tz.guess() for the selector does not work. This means that if we use this component on the appointment booking page, we need to find a way to aggregate timezones the same way.

[emrysal]

In reaction to that @50bbx; I opened an issue on ndom91/react-timezone-select#25 - let's see what comes back.

[ulentini]

From what I can see, react-timezone-select support all official Timezone names (because the spacetime package supports them), but it provides just a subset of them (removing duplicates).
If a complete list of timezones is passed in the timezones attribute, dayjs.tz.guess() can still be used.

[emrysal]

@50bbx With v1.0.2 this should now be possible 👍

[50bbx]

Thanks @emrysal it works!

See https://github.com/calendso/calendso/pull/163

[abrambailey]

Just a small issue here. The first image comes from my email ... The second comes from the icon to add to google calendar in the confirmation page. Not sure which one is wrong, but they can't both be right:

[emrysal]

@abrambailey I think this just got fixed in #181 - could you confirm?

[abrambailey]

Happy to help, has code been deployed to https://calendso.com/rick/quick-chat ?

[baileypumfleet]

Yes, should be running the latest code now.

[abrambailey]

So the emailed invite seems fine. There is a weird bug in the thank you page, the first time I click on the google icon, I get the wrong time. If I click back and try again, I get the correct time. I tried it twice.

[jimafisk]

Can confirm I'm seeing the same behavior as @abrambailey. Behind the scenes the meeting gets added to the correct timeslot, but if you click "G" icon in the "Add to your calendar" section of the booking confirmation page, it adds it in the wrong timezone.

Screenshot of confirmation page

Screenshot of the calendar event with incorrect time

I'm curious about the intention of this "add to calendar" feature if the event is already getting added to the calendar of the person based on their email address. Is it so the person requesting the appointment can add it to another calendar?