<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 2, 2017 at 8:06 AM, Daniel Ford <span dir="ltr"><<a href="mailto:dfnojunk@gmail.com" target="_blank">dfnojunk@gmail.com</a>></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"><span class="gmail-">"The library discussed in this list includes source code for one."<br>
</span>Oh, that sounds interesting, but I'm not sure where to look. Are you able to give me link?<br></blockquote><div><br></div><div><a href="https://www.iana.org/time-zones">https://www.iana.org/time-zones</a><br></div><div><a href="https://github.com/eggert/tz">https://github.com/eggert/tz</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">"Occasional synchronization should be sufficient, like existing radio clocks."<br>
</span>I was responding to your suggestion: "An even simpler design then would be to install software on the PC that would deliver the local time to your clock over the LAN. Get out of the TZ business altogether." With that scheme, as described, if the PC was not on when DST started/ended, the 'clock' would not be correct until the PC was on again.<br></blockquote><div><br></div><div>It would if the PC told the clock when/what the next UTC-offset transition was going to be.</div></div></div></div>