I've implemented exactly the filter you're describing. Yes, it's essentially a presentation issue.
There are 2 common ways to represent time: something akin to Unix time, which is just a scalar number representing the offset from some global reference instant (the epoch), or as "clock-calendar parameters" i.e. year-month-day-hour-minute-second. It's much more natural for software to operate entirely on the former representation right up to the point that the timestamps need to be either displayed as an output string for a human to read, or parsed from an input string from a human. Then you crack open tzdata [1] to do the conversion.
I think if your definition of "presentation" includes "parsing"; then we have very diverging definitions; but at least I understand we're mostly on the same page.
I programmed systems with both for many years -- the thing that needs to be defined early is whether your time an Instant or a Date/TimeOfDay/Quarter (collectively Naked)
Instant would be like log entry timestamp. Can be represented as unix time or SQL Timestamp.
Naked would be a "contract effective date" or "employment first day" or "invoice date" or "store opening time". Do not try to use an Instant to store it (e.g. timestamp at midnight to represent a day) or you're about to have a bad time later.
Instants are more prevalent in systems engineering, Nakeds -- in applications.
Only when you need to present the Instants to the user you need to convert them to strings and timezones come into play. Nakeds rarely need to be translated to Instants (e.g. when deciding if an invoice is overdue and send a email notification).
