<div dir="ltr"><div>
> Anyway, the bottom line is that the stopped clocks make this an oddball transition that cannot be modeled exactly by tzdb <br></div><div><br></div><div>Unless you're willing to have a slew of one-second-apart transitions with each one differing from its neighbor by one second.-)</div><div><br></div><div>    <a class="gmail_plusreply" id="plusReplyChip-0">@dashdashado</a><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 10, 2020 at 5:25 PM Paul Eggert <<a href="mailto:eggert@cs.ucla.edu">eggert@cs.ucla.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks for the heads-up. I also found a contemporaneous English-language source,<br>
the Brooklyn Daily Eagle Almanac (1912).<br>
<br>
Unfortunately, we have no good way to model stopped clocks in tzdb, as tzdb<br>
clocks are always running. So we need a transition of some sort, presumably<br>
either one like 2020a (from 00:01:00 local time to 23:51:39 the previous day),<br>
or the other, more-logical one (from 00:09:21 local time to 00:00:00 the same day).<br>
<br>
Now that I'm looking into it, the line "0:09:21 - PMT 1911 Mar 11 0:01 # Paris<br>
MT" that's currently in tzdb is surely a typo. It's not what's in Shanks, who<br>
gives a transition time of "0:00". Formerly tzdb had no time for that<br>
transition, which defaulted the time to 00:00. My patch dated 2001-03-13 changed<br>
this to "0:01", but this part of the patch patch was in response to an email<br>
dated 2000-12-20 (or -19) from Ciro Disceopolo<br>
<<a href="https://mm.icann.org/pipermail/tz/2000-December/011284.html" rel="noreferrer" target="_blank">https://mm.icann.org/pipermail/tz/2000-December/011284.html</a>> which says nothing<br>
about that "0:01". Evidently I mistakenly copied the "0:01" from the previous<br>
line "Zone Europe/Paris 0:09:21 - LMT 1891 Mar 15 0:01", where Shanks does say<br>
"0:01".<br>
<br>
Anyway, the bottom line is that the stopped clocks make this an oddball<br>
transition that cannot be modeled exactly by tzdb, and that given the story you<br>
mentioned you are correct that it's better modeled using an ordinary transition<br>
(from 00:09:21 to 00:00:00) than the unusual transition we're currently using. I<br>
installed the attached proposed patch into the development database.<br>
<br>
Given the above, we have a new trivia question: when and where could a stopped<br>
clock have been correct *more* than three times in a single day? Answer: a clock<br>
stopped at 00:00 was correct an infinite number of times that day in France.<br>
</blockquote></div>