Organization with more than 1 time zone and SharePoint calendars

Sorry, I might not be explaining the situation clearly.

We have 1 organization spanning 2 time zones. The entire organization needs to get dates and information from one single-purpose calendar (dates for internal professional development training events). That calendar lives in one single defined site collection set to eastern standard time. 

Our users in the central time zone have their Outlook clients defined to their local time zones.. Eastern time users have their set correctly and natively follow the SharePoint calendar more closely.

When a central time user views the calendar and sees an event that starts at 2:00 PM, they currently have to make a manual and mental note that this is really 1:00 PM for them.

They can download the ICS file for that event and add it to their Outlook calendar.  It will properly register for 1:00 PM local start time, which is good.

There is an individual setting (per user) in Office 365 for time zones.  This may not always contain data, so a separate and intentional effort (communication and training) needs to take place for our users to correct this.

The people creating and managing these events are in both time zones, so they will also have to be extra cautious and aware of what the real time of the even its, what the time will appear to people in both time zones, and what the time will be for users adding the event via ICS to their Outlook calendar. 

Here is the main question/issue:  There should be some automated ways of standardizing - or at least clarifying - this. 

One way would be to leverage metadata on the SharePoint side (i.e. add a column in the calendar list for time zone).  That would be helpful when viewing the event - EXCEPT that modern displays of events do not allow for usage or displays of custom metadata  (a big shortcoming in many "modern" displays).

Another way to handle this would be to have the SharePoint calendars be more like other Office 365 date tracking mechanisms (calendars leveraging Exchange Online?).  Like "real" or traditionally managed date and time data types. That is probably a longer road for development, but I don't know.

A lot to unpack here, but hopefully there can be some progress and likely, there are other organizations in a similar situation.

Thanks again!