> I was actually planning to write my own implementation for $language using unix timestamps as internal representation and requiring a timezone whenever parsing or printing
That does not and can not work when trying to represent future local events, which is the vast majority of them as an event normally happens relative to a specific geodesic location.
Astronomical events are more or less the only ones which actually routinely get planned in TAI / TT, and astronomical software is thus the only one for which this model could actually work. And then you wouldn't be using unix timestamps (because it's UTC).
That does not and can not work when trying to represent future local events, which is the vast majority of them as an event normally happens relative to a specific geodesic location.
Astronomical events are more or less the only ones which actually routinely get planned in TAI / TT, and astronomical software is thus the only one for which this model could actually work. And then you wouldn't be using unix timestamps (because it's UTC).