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.
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.
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.
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.