I think this is probably the cleanest fix, but I only tested event imports (which now appear to work). If you want to test Maniphest with subtypes configured (to make sure it doesn't break) and send me a revision with this change, I'll review it. Otherwise, I'll do that testing when I get a chance and land this if nothing crops up.

See Planning.

Is there someone working on this feature?

The apparent lack of support for scheduling in UTC in much more mature calendar software (Google Calendar / Calendar.app) further suggests that this is not an important feature for most users.

@epriestley what do you think of creating another column in the calendar_eventinvitee table, something like a bool futureStatus so that when we get a list of invitees back, we can check for that flag. I think this would mean a lot of date comparisons (seems inefficient), and I'm not quite sure when to populate event stubs. For example, if the futureStatus flag is set to true for instance 10, and there are stubs for instances 15 and 20, when would 15 and 20 get converted to have the updated status?

@mna Please follow our bug reporting guidelines if you feel you've encountered a bug. This task is several years old and not relevant.

Hi everyone, when I open the datepicker (e.g. via https://secure.phabricator.com/calendar/event/edit/form/default/ ) today (it is August 31st), then it defaults to today (August 31st).

@epriestley @jdiepenmaat If I may add ideas on that. I am using Things at the moment. There are only two reasons that hold me back to finally and completely switch to Phabricator:

• recurring tasks
• start dates for tasks

The latter is basically what your example is about, right? Because if I have just renewed the SSL certificate then a new task is created (due date being in one year), but it should not possible to start that right away, as it's not necessary. You would use a start date as well, wouldn't you?

I can confirm this.

This almost certainly has nothing to do with being invited via a project. I'm just going to merge this into T10448, which will moot it.

I've seen complaints about this on phabricator.wikimedia.org as well, so I can confirm that this is an issue.

Hm, this screenshot made me dig a bit into the whole thing, so here is what I've found:
First, my date format is different because of my settings:

• Default settings of this instance: F5042482, with date format: F5042480
• My default settings: F5042481 with my date format: F5042479

Why does your date format look different than ours? Is that a local modification or do we support this somewhere I'm not aware of.

Merging over so there is one thread on this topic. We're happy to reopen if you have new reproduction steps we can follow or if you can verify on a Phacility test instance.

I can't reproduce this (again)

Here's the proof: F5042439

I think it's probably reasonable for us to warn about RSVP'ing to an event which has already ended. I'd guess this is usually a mistake, and in cases where it isn't some kind of weird off-label workflow is taking place and the warning is probably fine.

Should not, but looks like there are. I updated to master now, and it works now.

I used the current version, but there should be no meaningful changes to this behavior between your version and HEAD.

That's weird since I exactly did the same with my version from above. Did you used the current or my version? Or should I update and try if I can reproduce it at the master?

I can't reproduce this. Here's what I did:

Version infos are:

phabricator
    0d1654446be6de43b2bd12fcc247db0dc1a46464 (Sat, Jun 10) 
arcanist
    c04f141ab0231e593a513356b3832a30f9404627 (Fri, Jun 9) 
phutil
    74a1350416eb2df825c2315d6519bee03f77bee9 (Mon, Jun 5)

In T7930#215278, @isfs wrote:

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.

The recurring and due date use cases in the previous comment would also be useful to us. I would prefer something more natural for the formulation, though, e.g. for tasks:

• when [Father Time] [reaches] value in [Due Date] (or other selected field), [Assign to] [ben].
• when [Father Time] [is one week before] value in [Due Date] AND [Status] is [any open status], [Set priority] to [High].
• when [Father Time] is [one month after] value in [Creation Date] AND [Status] is [any open status], [Send email notification] to [manager].

It would be great if task Due Dates (or other date fields, conceivably creation date could also be useful) could (optionally) appear on a calendar.

I cancelled and reinstated E1486 to force a cache clear with the new code, which seems to have resolved this in production.