<div dir="ltr">On 17 October 2017 at 10:23, <span dir="ltr">&lt;<a href="mailto:Paul.Koning@dell.com" target="_blank">Paul.Koning@dell.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The TZDB is exactly that: a set of rules. </blockquote><div><br></div><div>Precisely.  If you&#39;re more interested in the rules than individual dates, you probably want to consume the data files directly (africa, antarctica, asia, etc.) and then use the rules therewithin to compute dates as far out as you need.  (zic is the tool developed for this purpose.)  Just keep in mind, for all the reasons already mentioned, that you should check regularly for updates whenever possible.</div><div><br></div><div>On 16 October 2017 at 08:32, Daniel Ford <span dir="ltr">&lt;<a href="mailto:dfnojunk@gmail.com" target="_blank">dfnojunk@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The user can still enter their local DST rules manually, if/when they change.</blockquote><div><br></div><div>There are a handful of zones for which this can be more complicated than initially meets the eye.  The cases surrounding the dates of observance of Ramadan are certainly one such case, though as you note, most such areas have some sort of <i>de facto</i> &quot;buffer zone&quot; around the month for DST purposes, so the actual lunar observation is less important.  But also note that this means many of these locations are actually changing their clocks (possibly) four times a year, and according to two different calendar systems.  This is something that tz manages to approximate well, but that would be difficult to expect a typical end-user to program into an embedded device, if the underlying rules were to be tweaked.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">--<br>Tim Parenti</div></div></div></div>