In my opinion, it is possible to avoid inserting the field relating to the date and times of an Event in the model of the Event itself, as this information can be indicated in its first Session.
In fact, barring logical wreckage, in the case of multiple Sessions of an Event, it would still be necessary to indicate the information for each Session, including the first, so in my opinion you could simply make sure that you always have a first Session automatically generated with information relating to the date and times, and then be able to add more if necessary.
In this mode, the sorting of Events on the site could be based directly on the dates of the Sessions, and also allow logics in which Events can remain visible, if Sessions are yet to take place (perhaps with an option that allows you to avoid it when no appropriate).
In my opinion, it is possible to avoid inserting the field relating to the date and times of an Event in the model of the Event itself, as this information can be indicated in its first Session.
In fact, barring logical wreckage, in the case of multiple Sessions of an Event, it would still be necessary to indicate the information for each Session, including the first, so in my opinion you could simply make sure that you always have a first Session automatically generated with information relating to the date and times, and then be able to add more if necessary.
In this mode, the sorting of Events on the site could be based directly on the dates of the Sessions, and also allow logics in which Events can remain visible, if Sessions are yet to take place (perhaps with an option that allows you to avoid it when no appropriate).