We've recently made some changes to the internal storage representation of Calendar events. These changes primarily accommodate a broader range of date/time specifications and recurrence rules so we can represent (almost) any event which can be represented by an .ics file, which will let us import most ICS files in the future (see T10747).
(The features we do not plan to support are mostly for product reasons: for example, ICS files can represent events which occur once per second, but there is no real use case for these events in most calendaring software and other calendaring applications generally do not let you define them.)
If everything goes well, these changes should have no visible impact. They have been tested reasonably thoroughly, but the migrations are complex (especially the migration in D16664) and calendar data is also complex. It's possible that I missed some cases and that the migrations will incorrectly move/reschedule/corrupt existing events or cause other bugs.
Let us know if you notice anything suspicious: although Calendar is still a prototype, we don't expect to mangle any data more than strictly necessary. The migrations leave the old data behind for now and it is likely that we can fix any issues which are discovered in the relatively near future in a followup migration.
If your environment facilitates it and you have Calendar data in use, you may want to save a backup first or try these migrations against test data.
These should be the last major changes we need to make to Calendar event storage before we unprototype the application.