<div dir="ltr"><div>One quick-and-dirty possibility: in zic.c, set "early_time" to one billion (and downgrade the error about leap seconds before the big bang to a warning).<br><br></div><div>(While quick and dirty, this is considerably more refined than setting timecnt to zero.)<br></div><div><br></div> @dashdashado<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 18, 2017 at 1:59 PM, Viktor Sergiienko <span dir="ltr"><<a href="mailto:singalen@gmail.com" target="_blank">singalen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, May 18, 2017 at 10:39 AM, <<a href="mailto:Paul.Koning@dell.com">Paul.Koning@dell.com</a>> wrote:<br>
><br>
>> Limited savings is due to disk sector size; as an example, the "America/New_York" produced by an unmodified zic weighs in at 3545 bytes; on a 4096-byte-sector system, the one sector it takes can't be reduced.<br>
>><br>
><br>
</span><span class="">> That's a point. Note though that removing old information will also make for a bunch of duplicates, which reduces the total storage needed. Also, if you can use a storage system that packs the data, the sector issue may not be there. I could imagine, for example, storing the zone data in a zip file and extracting the desired file when the user says "I want to use zone America/Thule". In our own case, I used a dense file system similar to Linux's "romfs".<br>
><br>
<br>
</span>Yep, or we can mount an archive as is, with archivemount or something.<br>
The file slack can be dealt with, as long as the data is slimmed.<br>
<br>
Thanks!<br>
</blockquote></div><br></div>