> If it's all just an automated and finite offset, there's no reason for daylight savings policies to hew to 60 minutes adjustments.

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.

Moving up and down at a linear rate would result in a saw-tooth-like wave, but the length of days change in a sine wave. Why not have the clocks sync themselves to sunrise time based on their timezone and latitude? I don't think this would be much different, in practice, than changing times at a linear rate.

This would lead to a monumental amount of confusion.

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.

More than one car per individual seems already such a waste but multiplying this at million people level, is that a real thing in USA or are you just extrapolating in your own social bubble? I mean, I must admit that I had the thought that this was just a troll that leverage on gross exaggeration of some American stereotypes, but actually I just can't decide if you are plain serious about these statements.

I have two cars (just for me, not family). Paid about $6k in total for them. You can have multiple cars without being in any particular social class

Adding to my sibling comment, time is also mostly used as a coordination system. Being offset by a few minutes would make aligning meetings with your remote coworker an even bigger nightmare than it is now.

Why don't we take it to the extreme then? Just make the time the Sun rises 6am always. And make seconds longer or shorter to adjust.

The logical conclusion of going down that route would be to dispense with the concept of time zones altogether, and just revert to using local solar time.

Which would make scheduling Zoom meetings or even just phone calls hell.

Especially when everyone's half-hour blocks are misaligned with each other's so you can't even stack meetings efficiently.

And public transport timetables, which were the original reason timezones were introduced in the first place.

This is why I think we should entirely ditch the concept of timezones. Clock time, as we use it, is largely decoupled from solar time anyway, and all attempts to reconcile the two just lead to confusion.

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.

I figure everyone would just use local time locally, and unadjusted UTC for everything else.

> but this could 'solve' daylight savings time

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.

Permanent standard versus permanent daylight standard is an interesting debate because some of your preference depends on which edge of the timezone you live on. It is possibly a warning that hour-wide timezones are maybe too wide and that a solution to abolishing DST may need to better account for 30-minute or 15-minute wide timezones. Right now the swing back and forth does help keep one edge or the other happier to be in the same wide timezone. Of course "switch to smaller timezones so that we can drop daylight saving time" would complicate the "simple" choice to drop DST.

India is UYC+5:30, and doesn't do daylights savings time, which is interesting for interacting with the rest of the world. Of course, China famously has one time zone despite being really wide which makes things interesting both internally and externally.

Most of the world doesn't do DST either[1], nowadays it's mostly a European/American thing.

[1] See the map at https://en.wikipedia.org/wiki/Daylight_saving_time_by_countr...

In theory, this can be expressed in tzdb. Obviously, it will cause problems.

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.

Part of the issue with DST is that it makes it hard to have a consistent repeating weekly meeting time across multiple time zones that switch at different times (US vs Europe for example).

It would mean that the repeating meeting time would be at a slightly different local time every week.

> It really is quite flexible.

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.

Please don’t give them any ideas.