One of the biggest problems with tzdata is only mentioned in passing in the article:<p>> If you make a system that uses timezone data, think ahead. The timezone data is updated as often as 10 times a year or more. In case you have an embedded system that is not connected to the internet all the time, how can that processes be put in place to make sure it is updated?<p>A decade or so ago, nothing updated, and when DST changed, you had to reset every clock in the house. There was maybe a day or two of confusion where you couldn't remember if you changed a clock or not, but easily dealt with.<p>Now, in my house anyway, <i>almost</i> everything automatically switches (with the notable exception of my stove and microwave clocks, but heck, those still don't even have battery backup for when the power flickers). This is probably even more annoying, because now it's not a matter of remembering if <i>I</i> switched it (in the last day or so) or not, it's remembering if the <i>device itself switches automatically</i> or not. I can't remember stuff like that, so basically for a day or two after DST I don't trust any clocks at all.<p>Worse is when the devices still have the old (pre-2007) DST rules built-in. We're lucky in NA that the rules don't change <i>that</i> much, but when they do, they do break all these old devices. The most annoying item I had (notice past tense) was a beside clock that auto-set itself I believe based on the WWV [1] signal, and had a setting for time-zone and would of course do DST shifts automatically. Pretty neat, when I first got it, but after 2007, I had to manually change the timezone on this "auto-setting clock" 4 times a year.<p>[1] <a href="https://en.wikipedia.org/wiki/WWV_(radio_station)" rel="nofollow">https://en.wikipedia.org/wiki/WWV_(radio_station)</a>