having dealt with many worldwide TZ transitions in my day job, there are many examples that don’t fit any model…
Fiji often seem to make up transitions on a whim.
Chile have many TZ transitions that change year-on-year.
Egypt has been another area with TZ changes.
So there are plenty that may not fit this model.
I think the Windows model isn’t bad to follow as well - all you have to do is update / rewrite your local XML file when you want the “policy” to change, much the same as a windows TZ update hotfix does. Worst case is you need to fix it twice a year; it’s more likely one change a year would cover you. Do it when you change the batteries in your smoke detectors
Forgot to mention: Since Windows Vista, the OS contains a “time zone history” that actually tracks DST transitions over the years; “Dynamic DST”. So that you don’t need to assume that the DST transition date that this year observed was the same for last year; this helps accuracy of calculations stretching across years. Given that in the embedded world you hardly care about things that happen last week, this is probably not something you’d need to worry about too much, unless you had specific use cases like in Pyxis or other “intelligent” applications. I know I tend to go around resetting time on the microwave and things when DST changes, so not having to change it on a Fez or two is a bonus, even if i have to mop up if the rule changed on me.
I think your idea of making the settings updatable is a good one.
It also occurs to me that timezone management would be best handled within the .NETMF rather than having people like me built piecemeal, limited solutions.
In any case, if code like this is going to serve a broader role, then an open-source model facilitating multiple contributors would provide a better outcome.
