Sharing availability in an email

[tkunze]

My main use case for calendar-assistant is to share availability with others, via email (i.e., in text), in their timezone and with optional padding around existing events so I can still prep/capture before/after meetings.

This might be related to #57, but I believe that issue is more about continuous sharing. Here I am talking about one-offs.

Example

Customer (in Europe): "Can we hop on a 45-minute call next week with your lead engineer?" Me: _queries my (Pacific time) and my lead engineer's (Taiwan time) calendar for availabilities between 8 an 18 CET (Europe/Berlin), making ourselves both available between 6 and 24 o'clock. Using 24-hour mode for simplicity. (Note the repeat options -a, -s and -e and the new "output" time zone option -z):

% calendar-assistant avail "next week" \
    -a <me> -s 6 -e 24 \
    -a <my engineer> -s 6 -e 24 \
    -z Europe/Berlin -s 8 -e 18
; output displays intersection between both availabilities in CET, e.g.:

         8   9   10  11  12  13  14  15  16  17  18
Mon 5/3  ####                        ############
Tue 5/4                              ######    ##
Wed 5/5  ####                            ########
Thu 5/6  ####                                ####
Fri 5/7  

(All times CEST)

Me: copies/pastes the output in an email to the customer.

One more option that is important in this context (and I believe in all "availability" contexts): being able to specify a minimum padding around existing meetings. I should be able to query "show me availability for a 1h meeting tomorrow between 11 and 5p but leave at least 15 minutes before/after existing meetings in case they overlap."

That would be absolutely fantastic and crazy useful.

[flavorjones]

@tkunze I'm glad you're finding this gem useful.

Let me start by saying that we haven't been doing much active development on this library, but we'd welcome any PRs or effort you were willing to put in.

I'd like to explore what you're asking about here, in an attempt to discern the set of missing features and to maybe talk a bit about the user experience / workflow.

Starting with what calendar-assistant does today:

ca avail -a you@example,com,[email protected] -s 6am -e 11:59pm monday

and assuming that everyone's google calendar settings for primary time zone are correct, you should see something like:

[email protected], [email protected]
- looking for blocks at least 30 mins long
- between 6am and 11:59pm in America/Los_Angeles
- between 6am and 11:59pm in Asia/Taipei

Availability on Monday, May 3:

 •  9:00am -  9:45am PDT /  6:00am -  6:45am CST (45m)
 •  4:30pm -  5:00pm PDT /  1:30pm -  2:00pm CST (30m)
 •  5:30pm - 11:59pm PDT /  2:30pm -  8:59pm CST (6h 29m)

The things that would need to change are:

• ability to specify 24:00 as an end time that means end-of-day (currently this looks buggy)
• ability to specify an additional time zone to use when outputting time ranges
• (potentially) the ability to specify separate start and end times for each person or time zone

Does that sound right to you?

[tkunze]

Happy to help if I can but I haven't coded Ruby since my OpenShift days 10 years ago, so am probably more than rusty…

But regarding your example: I didn't realize ca already calculates start/end times based on each participant's local timezone. This is great!

Yes, so this use case boils down to the three items you mention:

1. Ability to specify 24:00 (or 12pm or 0am) as "end of day". This is a nice-to-have as I can work around that with minor editing.
2. Output time zone. This is huge as the goal is to present the times to customers in their time zone. I think this actually breaks down into 3 changes:
   1. Ability to set the output time zone. Huge.
   2. Ability to set output start and end times. This is not huge but important so we can allow more convenient times for customers.
   3. Automatic suppression of time display in input time zones (PDT and CST in our example here). Nice-to-have.
3. Different start and end times per person: nice-to-have.

In other words, the big one is (2). I thought I could force a different time zone on output by prefixing the command with TZ=Europe/Berlin but that doesn't work.