When you schedule an event in the future like “meet me at 14:00 in cafe foo”, this means local time and it’s going to mean 14:00 local time even when the timezone changes.

If you store this in UTC and the timezone changes, you end up converting to the wrong time.

So for future events you should store local time with a location you can map to a timezone.

The solstice is based on astronomical phenomena. If you store it in UTC it will always be right.

Unless there is a leap second scheduled on short notice or you install the updated tz database rather late. For astronomical events or long term measurements (think CERN) there is astronomical time, which does not add leap seconds.

But if you want to have precise date time far in the future you must not use UTC based milliseconds representations unless you want to check for necessary database migrations every time the time zone definitions change.

If you store zoned time in UTC then the zones or UTC change then the time can be formatted correctly in the future.

My point in mentioning the solstice is that while some events are at “2pm”, others are “when something happens”.

Sure, UTC is not suitable for conducting astronomy. It is suitable for working with human friendly times, since it is the foundation of timezones.