This is technically possible (and I believe imported events do have some support for mutation within Phabricator today: for example, I believe you can award them tokens). However, I'm very hesitant to start making imported events writable.

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.

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:

Do this man

Something that would be useful to us would be the ability to create, or probably better, assign a task, as it nears a due date. E.g. we may set up a task due in a year's time, and anticipate working on it two months before it is due. It would be great to be able to schedule the task to be assigned on a particular date, and perhaps moved on a workboard. I don't think this would need to be any more complicated than a Herald action that runs at a particular date/time rather than in response to some other action. I'm not familiar with what Calendar can already do, as we don't have prototype applications turned on for our install, so apologies if this is already possible. I just thought I would mention this use case here for future reference.

I believe we only get it wrong in the very specific case where you're attending a "Busy" event and an "Away" event at the same time. We'll show the dot color for whichever event started first, so if the "Busy" event started before the "Away" event you get an orange dot instead of a red dot (if the "Away" event started first, we show a red dot, but that's the right color to show).

rare

Maybe my calendar setup isn't common but I usually have multiple overlapping meetings each week - I know others at the same company manage their calendar in a similar fashion.

Here's the note in PhabricatorPeopleQuery about this:

Is there any way of getting Calendar enabled on a Phacility instance? We're looking to migrate from a self-hosted instance, and it's one of the applications we use to organise meetings, etc.

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

I've recently found myself wishing for couple kinds of functionality that would connect calendar and maniphest:

• "due date" for tasks,
• recurring tasks (just like events)
• age-based priority for tasks (dunno if calendar would be involved, but i've seen some instances of similar FRs popping up)

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

The most important aspect in flexibility is the ability to support all locales. MediaWiki uses a system largely based on PHP's date() for historical reasons, see Language::sprintfDate().

OK, it seems utcInstanceEpoch is only used in child event of recurring events according to the code. After I canceled the recurring event(E4), there is no more error in phd log.

I just created a simple test event and the utcInstanceEpoch column is still NULL. What does this column mean?

just FYI, I checked the database and found the utcInstanceEpoch is NULL for some old events, which maybe caused by bug in data migration during upgrade.

I wasn't able to reproduce this earlier so I'm not sure how to move forward, but feel free to follow up if you have more information.

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

Hmm, I'm having trouble reproducing this. Here's what I did:

Thanks, that's extremely helpful. I think D16974 + D16975 should fix the bug (and an adjacent bug I hit while testing the first fix).

Attached is a single VEVENT that causes "Datetime has no timezone or viewer timezone." in the calendar view after importing, the import itself runs fine.

In the general case:

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?

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

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

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

Why did you allow everyone everyone edit the event?

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?

Everyone can see from which url a calendar event came.

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.

Thank you! The new dialog looks excellent, it would have prevented my error.

Here's the revised dialog after D16956:

I don't think that edit is always invalid: offhand, one reason you might want to make such an edit is so that you can add a tag to all events in a series, allowing you to query them so they can be exported to another calendar. Another case I could imagine is wanting to correct a mistake in the description of an event when you know nothing will be lost by editing future events (e.g., because you are the only user who can edit the event).

Maybe it would also be sensible to not allow mass-edits to be triggered by past events. While it may be useful to tweak a single past event, I don't see much of a use case of updating all events starting from some past date. I'd argue that that is nearly always unintended.

• Availability cache build on All-Day events may be off, I didn't pick up a dot for E1222.

Couple of other things:

Thank you very much, I'll take a look :)

Thanks @epriestley for the reply. Seems like my mental model of "prototypes" along with the misleading wording of "future" threw me off.

As far as I understand, E66 acts as a prototyp (or template), providing defaults for when the individual instances are "materialized" later, when they are edited. Is that correct?

Hi @epriestley, thank you for your explanation.

E1218 seems to have worked properly after the patch, at least.

I'm pretty sure D16937 fixes this, thanks for the report! Let us know if you're still seeing issues after that.

Yeah, looks like that reproduced it. Here are the caches:

Sorry, can't make it this time! I'll catch you guys next time for sure.

Hmm, can you try creating a test event on this install to see if you can reproduce it here? I played around with this a little bit locally but wasn't able to get it to break.

It's like before: Neither the orange thing appears nor am I listed as "busy" at my profile. I'm listed as available there.

This all seems reasonable, I'm actually not 100% sure what happened so I'll try to gather a better understanding of the situation ;)

Generally, our behavior here is approximately the same as Calendar.app and Google Calendar. T11804 documents how various edge cases behave in those applications. I believe our behavior is no more spooky in any case I'm aware of.

Maybe this is a misinterpretation of "All Future Events"? That means "All events which start after this event starts", not "all events which have not yet occurred, considering the current time".

I'm still having trouble figuring out which past events were edited. Downstream has this query:

Oh, sorry, E66 would have been disconnected from past events by the edit. Let me look through the downstream task.

Assuming that's just a miscommunication, I can't immediately reproduce this locally:

E66 is the first event in the series, so I would expect editing E66 "All Future Events" to edit every event in the series: there are no past instances. Am I misunderstanding? What's an example of a past instance?

I created a test-event now, it starts in an hour, and I will take a look if this occurs again.

Although it's very possible that this is a bug, this state also has a 72-hour internal cache which wasn't written correctly in older versions of Phabricator.

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

@epriestley Yeah, you're right. There was a php5-fpm instance running, which i forgot to restart.