<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 25, 2015 at 1:56 PM, Stuart Bishop <span dir="ltr"><<a href="mailto:stuart@stuartbishop.net" target="_blank">stuart@stuartbishop.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":zq" class="a3s" style="overflow:hidden">On <span class="aBn" tabindex="0"><span class="aQJ">25 August 2015 at 21:51</span></span>, Alexander Belopolsky<br>
<span class=""><<a href="mailto:alexander.belopolsky@gmail.com">alexander.belopolsky@gmail.com</a>> wrote:<br>
<br>
> On Tue, Aug 25, 2015 at 9:30 AM, Stuart Bishop <<a href="mailto:stuart@stuartbishop.net">stuart@stuartbishop.net</a>><br>
> wrote:<br>
>><br>
>> As mentioned elsewhere, pytz requires strict checking to remain<br>
>> backwards compatible.<br>
><br>
> Can you provide the specific examples where strict checking is required?<br>
<br>
</span>Systems where it is better to fail than continue with incorrect<br>
results. For example, ingesting transaction logs. It is more desirable<br>
for the script parsing the log files to fail with a traceback than to<br>
feed incorrect results into the rest of the system, where some poor<br>
DBA is going to have to repair the cascade of damage months or years<br>
later.</div></blockquote></div><br>Speaking of DBAs, how would she feel if a system zoneinfo upgrade made her database unreadable?   A zoneinfo upgrade can easily create new gaps and folds even in the past if someone at IANA decides that they found a better source of historical information.</div></div>