Do you really need the timezone for each entry in the storage layer?

The application knows how it stores data, so it can just use UTC or whatever it likes. One timezone for all entries.

The interface then can display it in a way the user likes.

Depends on what you need.

If you specifically only care about moments in time, throwing away the input time zone might be fine.

If the application is more human centric, timezones are often very useful as humans move around but often think about time as timezone-relative. A log of your daily activities would be confusing if a past event logged as 09:16:01 suddenly showed up as 07:16:01 because you're travelling when viewing it.

This sounds like a footgun.

At some point some application developer will introduce a bug where they're not sending utc.

Without the time zone, the wrong times will end up in the database, bad data mixed in with good. This will be a nightmare to fix.

With the time zone, I don't think this class of bugs is possible. Most application developers will wrap the time in an object that allows them to do time operations without needing to directly handle time zone in most cases.

For timestamps/instants, sure you can just use UTC. But you cannot do human calendar math on instants, else you will ruin someone's entire day once you inevitably hit relatively common edge cases where civil time matters.

From bitter experience: yes, having TZ-aware dates and times everywhere is helpful, and saves you more in (lack of) trouble than it costs in storage and "hassle".

And then your country ditches/adopts the DST and you have angry customers because your app has messed up their future appointments.

You need time zone to parse time.