[1] See the map at https://en.wikipedia.org/wiki/Daylight_saving_time_by_countr...
Especially when everyone's half-hour blocks are misaligned with each other's so you can't even stack meetings efficiently.
We already have terms a few terms to tie events to solar time, for example, a park being open from dawn to dusk. And without time zones, we might come up with a few more.
For as long as clock sync for electronic devices has been common, I have suggested to anyone who would listen that we should adjust forward 10 minutes on the first Sunday of each month for six months, and then back 10 minutes on the first Sunday of the other six months. A ten minute change once a month is not only easier to adjust to (almost unoticeable), but if you miss it, it's not as big a deal as being off by an hour would be.
The primary time keeping device in my house is the clock on my stove; I wear old school watches a lot; and most of my cars are old and have old clocks in them. I can't be the only one, so multiply this by at least a few million other people in America alone.
Sure, you can tell everyone they need to ditch dumb clocks and replace them with internet-enabled smart clocks. But I think that's a far more onerous undertaking than just dealing with the fact that solar time and clock time are mismatched.
This ignores the easiest solution to daylight savings time.
Stop doing daylight savings time.
My preferred solution would be permanent standard time rather than permanent DST, but I'll take what I can get as long as we stop changing the clocks twice a year.
Other than considering current legally defined timezones as "legacy" definitions and then removing them for no reason other than to follow European fashion.
So, flexible, but managed by inflexible university types.
The only really important assumption not obviously present in TZif's data format is that when you go from a local time to a UTC time, there can only be up to two possibilities. A lot of software works on that assumption, for instance java.time.LocalDateTime has a withLaterOffsetAtOverlap():
https://docs.oracle.com/javase/8/docs/api/?java/time/LocalDa...
That implicitly assumes that whenever it's ambiguous what 2:30AM means, you can only have two possible solutions (pre- and post-DST). If a timezone were ever to manipulate its offsets so that there were three or more solutions (such as if they did a "fall back" at 2:00AM and then 2:15AM or something), a lot of stuff would be unable to represent that.
It would mean that the repeating meeting time would be at a slightly different local time every week.
It leads me to wonder. If it's all just an automated and finite offset, there's no reason for daylight savings policies to hew to 60 minutes adjustments.
Couldn't a nation decide to have a continuously changing offset throughout the year? It might make their offset lookup table substantially longer, but this could 'solve' daylight savings time It'd be adjusting all the time and you wouldn't notice, just you don't notice when leap seconds occur.
Those who rely on analog clocks might no longer adjust the same direction each time!