Technically, nobody lives in "UTC". You might say people live in UTC+0, which is a standard time zone around the prime meridian. UTC refers to the system of standard time zones, not a single time zone, but in common speech "UTC" is often understood to mean UTC+0.
Let's say you live in California. During the winter, you observe PST ("standard time"), which is UTC-8. During the summer, you probably observe PDT ("daylight time"), which is UTC-7. Switching between the two is sort of outside the scope of the UTC system. It happens locally and is subject to local social and political preferences. Digital clocks mostly just keep track of standard time and possibly adjust their output if presenting a human-readable timestamp string.
Leap seconds are very much inside the scope of UTC. A leap second occurs globally for every standard time zone at the exact same global instant. It's determined by an objective criterion based on UT1.
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).
