I think the best solution, as discussed in chat, is point 3, programmatically adding a draft (or custom post status) via the use of wp_insert_post where amongst other parameters you can set the likes of;
'post_date' => [ Y-m-d H:i:s ] //The time post was made.
'post_date_gmt' => [ Y-m-d H:i:s ] //The time post was made, in GMT.
…without having to intercept gmt_offset via pre_option_gmt_offset which is a dead end anyway.
Also replacing the publish meta-box, cloning it, rebuilding it, whatever and whichever way you want to say it – is a potentially disastrous maintenance nightmare.
If we think about this, adding a draft (or custom post status of your choosing) is far less trouble than the aforementioned ideas.
The only downside to wp_insert_post is that we are physically inserting a post into the database, so in some respect we are polluting the database with what normally would be an auto-draft.
That’s where wp_cron comes into play.
Depending on whether you stick with the draft post status, as you mentioned in chat, you might want to add a custom field (prefixed with underscore) that can be used to flag these post entries.
IF the user does not publish the entry, then we can consider this post item was discarded by the user and thus should be marked for cleanup.
I would even go as far as adding a custom admin notice that indicates to the user that if they do not publish the post, it will not be added to calendar as an entry and will be earmarked for cleanup at a later date.
This is the safest, sanest and most future proof solution available until (if ever) we get the ability to programmatically set form inputs on the post edit screen via query variables other than (post_title/content/excerpt) which seem to be the only ones that currently work.
The only other option that I can think of would be to set the value of the date inputs via JavaScript and or jQuery – which would be easy to do but you have no guarantee that the user has JavaScript enabled, which if they did not – this would fail.
We know some edge-cases exist for custom post status that may be of concern but considering their usage in your application I think the risk is minimal in using them