• 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.

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

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 outlook.office365.com. The ics contents include:

BEGIN:VTIMEZONE
TZID:W. Europe Standard Time
BEGIN:STANDARD
DTSTART:16010101T030000
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T020000
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE

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:
  

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):

https://msdn.microsoft.com/en-us/library/ms912391(v=winembedded.11).aspx

Is this the complete list?

https://msdn.microsoft.com/en-us/library/ms912391(v=winembedded.11).aspx

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?

In T11816#202107, @epriestley wrote:

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.
https://secure.phabricator.com/book/phabricator/article/calendar_imports/

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.
https://secure.phabricator.com/book/phabricator/article/calendar_imports/

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

Getting Datetime has no timezone or viewer timezone when viewing the main calendar.(https://gist.github.com/carlokok/570d524fe2a6dd1472835c0fa67b7faf) 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

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 (https://secure.phabricator.com/calendar/export/3/):

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:

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

This is her status at 13:45 today:

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 https://phab-01.wmflabs.org/calendar/query/month/2017/10/ . 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.

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

@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.