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 added some log in src/applications/calendar/storage/PhabricatorCalendarEvent.php before line 728 like this:

if ($this->isChildEvent()) {
      $parent = $this->getParentEvent();
      error_log("utc string:".$this->getUTCInstanceEpoch(),3,"/tmp/phadebug.log");
      $instance_datetime = PhutilCalendarAbsoluteDateTime::newFromEpoch(
        $this->getUTCInstanceEpoch());
      $recurrence_id = $instance_datetime->getISO8601();
      $rrule = null;
    }

It indicates $this->getUTCInstanceEpoch() returns empty or null. Any help for this? And I guess it should be related to some recurring events.

No idea, I guess this is something related to the Calendar events in my install as you mentioned. I'm wondering if there is some place in the code I can add some lines to log/debug the actual event and the date/time string which caused the error? I can edit the source and run it again.

I'm still seeing this in the latest code:
phabricator

c63ba8337ec7e7f021f17c972e9a2a751f6280e2 (Sat, Jan 21)

arcanist

9503b941cc02be637d967bb50cfb25f852e071e4 (Sat, Jan 7)

phutil

6d8f5a783ebe7993b78632091507f6d7d8cbc215 (Sat, Jan 21)

Actually this error started quite long ago. In my memory it started after some big changes on Calendar app. I have updated several versions before I fired this bug report. I will try to update to the latest version later. Regarding the reproduction steps, this is a background daemon log, not triggered by direct human action. I have no idea how to provide the reproduction steps. Any hint?

Any estimation how long can this be fixed? If it takes long, I will break the parent/subproject relationship. Otherwise I can just wait for the fix.

Well, it turns out I mis-typed the project name! It's just the error message not so friendly. I can reproduce the error with this:

./move_beneath.php --parent aaa --child bbb --keep-members both --subproject

OK, I got it worked for 2 other projects. So there must be something special with the 2 projects I tried previously.

Thanks, I will try to test more.

Yes, It was some local encoding handling related and should not be related to the error. My code base is this:

It seems the move_beneath.php doesn't work any more with the latest code.

I just looked the description in 74e117ae41dd.

In T11012#176923, @chad wrote:

We require reproduction steps on all bug reports, this way we know we're fixing your actual bug, and have a means to test and verify any fix. As Owners was recently overhauled with many new features, it's hard to identify what case we may have missed in testing.

I understand that. Will try to find reproduce steps.

In T11012#176731, @chad wrote:

This may also be T11015.

In T11012#176668, @chad wrote:

Please follow all the steps in Contributing Bug Reports. Specifically we need to know how to reproduce the issue locally.

well, I can still see the same error with new tasks.

OK, as @shrinidhirao suggested, the fix only works for new tasks. I canceled all failing tasks and wait to see how new tasks work.

I have the same error with the latest code even after I applied the fix from @shrinidhirao.

There is nowhere to delete/disable the package after this fix?

I got the same problem. Any fix for it?

yes. It's not related to php. Even this bash script hangs on my system:
$ cat /tmp/hw.sh
#!/usr/bin/env TERM=dumb bash
echo "hello world"