When you run into these exceptions, I assume the additional information only causes more problems than it’s worth? Thinking about Postgres’ official stance on storing timezones:
Time zones, and time-zone conventions, are influenced by political decisions, not just earth geometry. Time zones around the world became somewhat standardized during the 1900s, but continue to be prone to arbitrary changes, particularly with respect to daylight-savings rules. PostgreSQL uses the widely-used IANA (Olson) time zone database for information about historical time zone rules. For times in the future, the assumption is that the latest known rules for a given time zone will continue to be observed indefinitely far into the future.
They go onto say that storing time with a timezone is essentially meaningless without a date. Not only for applying mathematical functions to dates in the past, but external changes in how a region might measure time into the future.
I assume you also see time stored as an offset in some systems, e.g. UTC +2. Which also lacks the specificity to be really dependable for the same reasons. Ugh. No wonder you’re seeing ludicrous measurements of ~26 hours.
Is this a market opportunity to supply a single source of truth to (what remains of) the travel industry? Fractions of a cent per transaction just to read a clock accurately?