Page MenuHomePhabricator

Calendar: Feedback and Suggestions
Closed, ResolvedPublic

Assigned To
Authored By
Nov 3 2016, 6:55 PM
Referenced Files
F4831548: Screen Shot 2017-04-10 at 4.07.58 AM.png
Apr 10 2017, 11:15 AM
F4831570: Screen Shot 2017-04-10 at 4.09.16 AM.png
Apr 10 2017, 11:15 AM
F4291486: _133__⌨_E301_AB_Testing.png
Mar 27 2017, 6:37 PM
F4291458: calendar.png
Mar 27 2017, 6:37 PM
F4291474: busy_status.png
Mar 27 2017, 6:37 PM
F2312170: All day recurring
Jan 6 2017, 5:28 AM
F1923474: All day event tooltip
Nov 16 2016, 4:31 AM
F1921563: Off-screen date picker
Nov 14 2016, 8:49 PM
"Love" token, awarded by 0.


Calendar is nearing unprototyping (T7924). Although it likely still has a number of bugs and problems, I think the fundamentals are solid enough that we can now productively respond to feedback and bug reports.

In particular, we're interested in:

  • Bug Reports: If you poke around Calendar and notice issues, let us know. Issues with ICS import can go in the dedicated task for ICS imports, T11801. Before reporting a bug, please update to HEAD of master and make sure the issue reproduces there.
  • Use Case Feedback: Do you want to do something with Calendar that it doesn't seem to be very good at? We're interested in understanding your use cases.

We're more able to fix things and accommodate feedback in the near future (before unprotyping, and while still working actively on Calendar) than we will be in the long run, so your feedback is most likely to be addressed promptly if you're able to take time to submit it in the next week or two.

To get started with Calendar, see:

For some planned future work to Calendar and sense of what we're planning to do with it, see the Calendar workboard.

Revisions and Commits

rPHU libphutil
rP Phabricator

Related Objects

Mentioned In
T11073: Allow the user to specify a date in a different timezone using date controls
T11801: Calendar: ICS Import Errata
2016 Week 45 (Early November)
Mentioned Here
D17644: Make Calendar recurrence sets return the indexes of recurrence dates properly
D17645: Fix an issue where recurring ghost events could go missing if queried with a limit
T11399: Add support for locations in calendar events
T12488: Old Calendar events didn't get a utcInstanceEpoch populated, causing fatals on export
T11073: Allow the user to specify a date in a different timezone using date controls
E1209: Pull that into png
E1222: Pup Duty
E1220: Thanksgiving
E990: Remark up?
D16880: Use the same date rendering display logic for both tooltips and subheaders
D16879: Fix an issue where All Day events could return a DateTime with the wrong timezone
D16877: Translate windows timezones into Timezone DB timezones using the CLDR map
D16878: Make some confusing/weird Calendar fields not configurable on custom EditEngine forms
T10222: Consider soft-locked and mergeable EditEngine field settings
D16866: On tablet/mobile, open the datepicker control in the center of the screen and mask the background
D16865: When importing ICS files, map "W. Europe Standard Time" to "Europe/Berlin"
D16867: Fix a bug on Calendar event day views for all day events in certain timezones
D16868: Improve Calendar event behavior for group invites
D16870: Make Calendar query for indirect invites/RSVPs by default, like Differential
E1211: All day test
D16852: Restore green color on mobile calendar month view when a day contains events you are invited to
D16819: On `@username` mentions in remarkup, show the "busy" dot color
D16800: When we encounter a fanciful timezone identifier, try to guess what it might mean
D16801: Raise ICS warnings in Phabricator on ICS import
D16803: Fix an issue with editing application default policies in Calendar
D16802: Allow users to mark themselves as "Available", "Busy" or "Away" while attending an event
rPe4c6ae534518: Smooth out various transaction/editing behaviors for Calendar
rPbd256e9f3fdb: (stable) Promote 2016 Week 44
T7924: Unprototype Calendar (v1)
T11801: Calendar: ICS Import Errata

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
  • D16852 should fix the coloring on the mobile month view.
  • The icon means you're invited, not that other users have joined the event. Could we pick an icon that you'd find more clear? (Available Icons).
  • Old events have undergone several migrations and probably aren't unambiguously fixable at this point, so I don't expect to correct any remaining migration issues.
  • I can't reproduce the last issue you describe ("but are extended forward by a day on the event page"). Can you provide specific reproduction instructions?
  • LGTM, thanks.
  • That icon makes sense now that I know what it indicates. I doubt that there's a universal icon for this particular purpose. Maybe something like (or the open version added in the newest FA), but that's still unclear if you don't already know what it means.
  • That's reasonable.
  • I created the all day event E1211 to span the 14th and 15th (see image below). It appears correctly in the month view, but the event page says:

Hosted by 0 on Mon, Nov 14 - Wed, Nov 16, All Day.

Creation of E1211 (605×1 px, 42 KB)

eadler added a project: Restricted Project.Nov 14 2016, 8:13 PM

When creating an event, the date picker may be drawn partly off the screen:

Off-screen date picker (1×1 px, 70 KB)

The screenshot is from mobile (where the date picker is mostly unusable), but I can reproduce it to a lesser extent on my computer by zooming in a lot.

ICS import does not seem to parse VTIMEZONE entries in the ICS file. This is perhaps related to the Zimbra issues above, though in my case I am importing from The ics contents include:

TZID:W. Europe Standard Time

and entries with dates defined as:

DTSTART;TZID=W. Europe Standard Time:20160816T100000
DTEND;TZID=W. Europe Standard Time:20160816T110000

which gives warnings like below, and times end up offset as if the timezone was applied twice.

Calendar Import 3: Outlook Calendar		ICS Parser Warning	Warning ("warn-tzid-ignored") while parsing ICS data (near line 1703): TZID "W. Europe Standard Time" is unknown, using UTC instead.

The implementation effort required to support arbitrary VTIMEZONE entries would be fairly huge, since we'd need to reimplement the PHP builtin classes DateTime and DateTimeZone and basically write a full date handling engine. I believe there is no compelling reason for software to ever specify an event in a timezone which is not part of timezonedb (I believe timezonedb is accurate, exhaustive, and fairly ubiquitous; and RFC5545 mentions it, although it does not require it be used), although mapping VTIMEZONE names to timezonedb names may be difficult.

For now, I'll map "W. Europe Standard Time" to "Europe/Berlin", since that's what this authoritative-looking list says is correct (sort of) and the offset (+0100 vs +0200) appear to match up correctly, even though the corresponding modern names of the timezones are "Central Europe Time" and "Central Europe Summer Time".

If we continue running into unusual timezone names we can try to embed a more complete mapping like the list above or evaluate the actual rules against timezonedb rules to identify the correct timezone, although this is likely very involved because the VTIMEZONE definition and timezonedb definition of a timezone are very different. Hopefully these outlying timezones are fairly rare and mostly specific to old versions of Zimbra or Outlook-users-sending-stuff-to-Zimbra or something.

  • D16865 should treat "W. Europe Standard Time" as "Europe/Berlin". We'll figure out some better solution for this if it continues being an issue, I'm just still hopeful that we can get almost-correct coverage with a handful of explicit mappings/rules without needing to do anything more complicated.
  • D16866 should give the datepicker more reasonable behavior on mobile/tablet devices (the panel should now center on screen when activated).
  • D16867 should fix the issue with all-day events sometimes extending too far in the summary text on the day view.
  • D16868 improves behaviors around inviting projects to events on the day/month/detail views.
  • D16870 makes a query for "Invited: epriestley" mean "events which epriestley is invited to, or any project that epriestley is a member of is invited to". You can find just individual invites with "Invited: exact(epriestley)".
  • D16866 is just what I needed, thanks!
  • D16867 fixes what I reported, but I hadn't noticed that the month view tooltips are also affected in the same way:
    All day event tooltip (239×642 px, 10 KB)

Unfortunately "W. Europe Standard Time" is just one of the many unnecessarily verbose timezone names that Microsoft uses. I also had "Singapore Standard Time" and "Russian Time" (which I presume refers to Moscow, rather than any of the other dozen or so timezones in Russia) in my calendar for this week.

But if building a mapping is the way to go for now, a list of Microsoft's idea of timezones seems to be here (except my calendar definitely has Russian Time, not the Russian Standard Time shown in that list):

Whoops... just read your full comment. Sorry for dupe.

It's my fault - I edited the comment to add that link (probably based on
the same search you did) in parallel with your reply.

Some other stuff:

  • Editing the EditEngine default form allows you to prefill "Recurring" and "Frequency", but probably should not.
  • We should probably drop "All Day Event" from this form too, since it's sort of confusing and I can't really imagine much of a use case for it.
  • Editing the EditEngine default form prefills your own name as the host, but should not.

Maybe future:

  • When you click a day view to create an event in a timeslot and multiple create forms are available, we use the first one. This might be fine. We could give you a dropdown instead. Similar issue to how "Create" works on workboards.
  • Editing the EditEngine default form and removing "Host" means that "Host" no longer prefills. This is the same as T10222. A temporary workaround would be to prevent that field from being defaulted. It should be defaultable in the long run, but is probably low-value to assign a default to, so it's probably better to just lock it for now and make it behave a little more sensibly.
  • D16877 includes the entire CLDR "windows to the rest of the world" map in things we'll recognize.
    • Neither that map or the Microsoft map have "Russian Time", but maybe that's just what the UI shows for zones like "Russia Time Zone 10", and not what actually appears in the ICS file? Otherwise we're going to have to keep digging.
  • D16878 fixes the form customization stuff I mentioned above, mostly by preventing quirky/confusing fields from being customized (at least, for now).
  • D16879 fixes a rendering bug with "All Day" events that could shift them forward or backwards by a day.
  • D16880 uses the same rendering logic for subheaders (which now appears to be correct) and tooltips (which had a different, older copy of very similar logic).

The Event Hovercards are not really useful: E990 The Mouse-over dialog shows no date and time for example...

Couple of other things:

  • Reminder for E1220 (an All-Day event) went out at the wrong time (5PM local).
  • Edits to DateTime objects should be no-op'd if they only change the timezone of an absolute DateTime (e.g., a no-op edit by a user in a different timezone).
  • Availability cache build on All-Day events may be off, I didn't pick up a dot for E1222.

My only concern with the current ics importing is that the url for importing from google, owncloud/nextcloud usually contains secrets other users shouldn't see, like in the case of owncloud: un/pw. Everyone can see from which url a calendar event came.

Everyone can see from which url a calendar event came.

This isn't expected. Can you give me reproduction steps for this?

Everyone can see from which url a calendar event came.

This isn't expected. Can you give me reproduction steps for this?

Create a new recurring ics import, set policy to all users view/edit (because I want everyone to see the events)
Wait for the import to finish, as another user, check any of the events and click "Imported By ck from Calendar Import 3: team"
Notice how the import page has the full url.

Why did you allow everyone everyone edit the event?

Did you see this note in the documentation?

Privacy Note: When you import via URI, the URI often contains sensitive information (like a username, password, or secret key) which allows anyone who knows it to access private details about events. Anyone who can edit the import will also be able to view and edit the URI, so make sure you don't grant edit access to users who should not have access to the event details.

How did you expect editing the event to work if editors aren't allowed to see the URL?

My apologies. I read over that bit and presumed it meant edit the calendar items

Hmm, I'm guessing this wasn't clear from the workflow either, then?

When you import events from another application, they can not be edited in Phabricator. Importing events allows you to share events or keep track of events from different sources, but does not let you edit events from other applications in Phabricator.

It makes sense in retrospect, but not from the workflow no.

Getting Datetime has no timezone or viewer timezone when viewing the main calendar.( after import. Since the import contains a quite a bit of private data, how can I narrow down which record specifically it fails on?

In the general case:

  • Download the .ics file to your desktop.
  • Open it in a text editor.
  • Delete half the VEVENT entries.
  • Delete all the imported events from the first import.
  • Import the modified .ics file.

If the issue persists, the remaining half of the VEVENT entries have a reproducing event. Continue with them.

If it does not, the deleted half did. Revert the file, delete the other half, verify that the issue persists, then continue with them.

Repeat this process until you have a single reproducing VEVENT record.

Edit the record to anonymize any information. Verify it still reproduces the issue, then upload it here.

When I try to make E1211 recurring (see screenshot below), I get

Unhandled Exception ("InvalidArgumentException")

Argument 1 passed to PhutilCalendarAbsoluteDateTime::newFromDictionary() must be of the type array, null given, called in /core/lib/phabricator/src/applications/calendar/xaction/PhabricatorCalendarEventDateTransaction.php on line 40 and defined

All day recurring (291×1 px, 32 KB)

Future instances of recurring events aren't visible in panels when an item limit is set:

  1. Create a weekly recurring event (E1376)
  2. Go to Upcoming Events view and see future instances of the event.
  3. Create a panel containing the Upcoming Events query (W540)
  4. The list will contain future instances of the event.
  5. Set a limit on the number of entries (eg. 5)
  6. Future instances are hidden. Non-recurring event E1209 is visible, although it's planned on a much later date.

When accessing an ICS export of all events I can see (

Unhandled Exception ("Exception")	
DateTime::__construct(): Failed to parse time string (@) at position 0 (@): Unexpected character
[Tue Feb 14 12:43:57.391659 2017] [:error] [pid 32692] [client xxx.yyy.zzz:62067] [2017-02-14 12:43:57] EXCEPTION: (Exception) DateTime::__construct(): Failed to parse time string (@) at position 0 (@): Unexpected character at [<phutil>/src/parser/calendar/data/PhutilCalendarAbsoluteDateTime.php:63]
[Tue Feb 14 12:43:57.392075 2017] [:error] [pid 32692] [client xxx.yyy.zzz:62067] arcanist(head=stable, ref.master=e8a0ebaeffaa, ref.stable=9503b941cc02), phabricator(head=stable, ref.stable=c3bdcb4ca854, custom=3), phutil(head=stable, ref.master=dad3ab8d7e87, ref.stable=10963f771f11)
[Tue Feb 14 12:43:57.392085 2017] [:error] [pid 32692] [client xxx.yyy.zzz:62067]   #0 <#2> DateTime::__construct(string) called at [<phutil>/src/parser/calendar/data/PhutilCalendarAbsoluteDateTime.php:63]
[Tue Feb 14 12:43:57.392088 2017] [:error] [pid 32692] [client xxx.yyy.zzz:62067]   #1 <#2> PhutilCalendarAbsoluteDateTime::newFromEpoch(NULL) called at [<phabricator>/src/applications/calendar/storage/PhabricatorCalendarEvent.php:728]
[Tue Feb 14 12:43:57.392091 2017] [:error] [pid 32692] [client xxx.yyy.zzz:62067]   #2 <#2> PhabricatorCalendarEvent::newIntermediateEventNode(PhabricatorUser, array) called at [<phabricator>/src/applications/calendar/util/PhabricatorCalendarICSWriter.php:50]
[Tue Feb 14 12:43:57.392094 2017] [:error] [pid 32692] [client xxx.yyy.zzz:62067]   #3 <#2> PhabricatorCalendarICSWriter::writeICSDocument() called at [<phabricator>/src/applications/calendar/controller/PhabricatorCalendarController.php:13]
[Tue Feb 14 12:43:57.392097 2017] [:error] [pid 32692] [client xxx.yyy.zzz:62067]   #4 <#2> PhabricatorCalendarController::newICSResponse(PhabricatorUser, string, array) called at [<phabricator>/src/applications/calendar/controller/PhabricatorCalendarExportICSController.php:97]
[Tue Feb 14 12:43:57.392100 2017] [:error] [pid 32692] [client xxx.yyy.zzz:62067]   #5 <#2> PhabricatorCalendarExportICSController::handleRequest(AphrontRequest) called at [<phabricator>/src/aphront/configuration/AphrontApplicationConfiguration.php:269]
[Tue Feb 14 12:43:57.392103 2017] [:error] [pid 32692] [client xxx.yyy.zzz:62067]   #6 phlog(Exception) called at [<phabricator>/src/aphront/handler/PhabricatorDefaultRequestExceptionHandler.php:41]
[Tue Feb 14 12:43:57.392106 2017] [:error] [pid 32692] [client xxx.yyy.zzz:62067]   #7 PhabricatorDefaultRequestExceptionHandler::handleRequestException(AphrontRequest, Exception) called at [<phabricator>/src/aphront/configuration/AphrontApplicationConfiguration.php:678]
[Tue Feb 14 12:43:57.392109 2017] [:error] [pid 32692] [client xxx.yyy.zzz:62067]   #8 AphrontApplicationConfiguration::handleException(Exception) called at [<phabricator>/src/aphront/configuration/AphrontApplicationConfiguration.php:274]
[Tue Feb 14 12:43:57.392112 2017] [:error] [pid 32692] [client xxx.yyy.zzz:62067]   #9 AphrontApplicationConfiguration::processRequest(AphrontRequest, PhutilDeferredLog, AphrontPHPHTTPSink, MultimeterControl) called at [<phabricator>/src/aphront/configuration/AphrontApplicationConfiguration.php:181]
[Tue Feb 14 12:43:57.392126 2017] [:error] [pid 32692] [client xxx.yyy.zzz:62067]   #10 AphrontApplicationConfiguration::runHTTPRequest(AphrontPHPHTTPSink) called at [<phabricator>/webroot/index.php:17]

We encountered a weird bug: a colleague was shown as Busy today because she's attending an event that takes place tomorrow. Calendar on her profile page:

calendar.png (341×322 px, 14 KB)

Event 'A' takes place tomorrow 13:00-14:00. She doesn't have any events till 14:00 today.

_133__⌨_E301_AB_Testing.png (998×2 px, 113 KB)

This is her status at 13:45 today:

busy_status.png (117×1 px, 14 KB)

I'm not sure how to go about reproducing this one.

I have noticed some strange behaviour with recurring events, which I've first documented at Wikimedias Phabricator. It's about what every programmer I know hates: Daylight saving times. Short version is: Phabricator locks time windows of recurring events to the time the event creator had in his time zone settings when he created the event, but does neither give an option to select another time zone to lock to nor does even show which time zone this is currently locked to.

That is, if I, having my personal time zone settings set to Europe/Berlin, create a event today and set it to begin at 8AM tomorrow and recur daily, it will always begin at 6AM in my time zone, which is UTC+2 currently, so it will start at 4AM UTC until 28th Oct 2017. As of 29th Oct 2017 it will start at 5AM UTC, as my time zone will have stopped observing daylight saving that day. This example - exactly as described - can be observed at . Just look for the event named "Test: Europe/Berlin". So currently, if I want to set up a recurring event which is locked to an other time zone, I need to go to my preferences, set my personal time zone accordingly, create the event(s) as needed, go back to my preferences and change my time zone back. There should be an option to select which time zone to lock an recurring event to when making an event recurring. While at it, an option at creation of the event which lets you define which time zone you're refering to (which defaults to your personal settings) when typing in times would be even more intuitive.

If there is anything horrible hard about fixing this, some hint at the window where you make events recurring which states which time zone the event is currently locked to, making the user aware, would be better than things are now.

@EddieGP, see T11073.

How do you currently schedule an event in UTC in other software?

I can't figure out how using Google Calendar -- I can't find any option in this dropdown which let me, but maybe I'm just overlooking it? There are approximately 9 million options. I looked for "International", "UTC", etc.

Screen Shot 2017-04-10 at 4.07.58 AM.png (1×554 px, 156 KB)

I can't figure out how in either -- I don't see any way to change the timezones of an event.

Screen Shot 2017-04-10 at 4.09.16 AM.png (315×461 px, 38 KB)

@ivo, I'll follow up for this on T12488 which appears to be a similar standalone report:

DateTime::__construct(): Failed to parse time string (@) at position 0 (@): Unexpected character

This is her status at 13:45 today...
She doesn't have any events till 14:00 today.

I think this is expected: you are marked busy about 15 minutes before events start. This allows some time for wrapping things up, travel, etc. The assumption is that, for most types of events, you are not actually responsive at 13:59 if you have an event starting at 14:00.

This may be too much time for virtual events, and too little time for off-campus events, but ideally I'd like to make travel time computation an artifact of support for locations (T11399). The current behavior is based on a guess that 15 minutes is probably fairly reasonable in most cases.

The profile detail does appear to show the wrong event. I think I'm able to reproduce this locally.

Future instances of recurring events aren't visible in panels when an item limit is set:

Thanks! I believe this is fixed by D17644 + D17645.

I'm going to close this as resolved since the initial rush of bugs and feedback has subsided and I think everything here has now been addressed or has a followup elsewhere. Feel free to file future issues as separate tasks.