[tz] [Tzdist-bis] [calsify] tzdist and IANA -- estimating the operational parameters

Ken Murchison murch at fastmail.com
Thu Jul 18 20:26:11 UTC 2019


On 7/18/19 4:15 PM, Paul Eggert wrote:
> Steve Crocker wrote:
>> Early in this thread it was mentioned the the time zone database 
>> should be
>> served in a fashion similar to DNS.  My first thought was the numbers 
>> are
>> wildly different.  I jotted down a first cut at identifying the relevant
>> operational parameters.  Perhaps the people proposing this service can
>> flesh out the quantitative aspects.
>
> Here are some estimates. There is no central TZDIST server now, so all 
> the non-size estimates are for if/when that happens. The estimated 
> rate of change for these numbers is all zero, except for the database 
> size where I'd estimate a growth of 5%/year (this is just off the top 
> of my head).
>
>
> Frequency of database update: 18 times per year has been the worst 
> case since the project started in the 1980s. Recently updates have 
> occurred three to ten times per year.
>
> Frequency of access: If we're assuming a pull model like TZDIST with 
> primary and secondary servers, I would expect queries once every 
> hour-or-so from each downstream server that wants to be up-to-date. 
> Usually the response will be "nothing has changed".
>
> Required response time: Most clients and servers can be expected to 
> have a (possibly-stale) copy of the data already, which they can fall 
> back on. So I would say "minutes".
>
> Required uptime: Again, not crucial. I would say 90% would be enough.
>
>
> For sizes, it depends on data format and whether you want all the data.
>
> Size of entire tzdb database (including all time zone history, version 
> info, and legal notices), in minimal source-code (text) form: 111 kB 
> uncompressed, 27 kB compressed via gzip, 22 kB compressed via lzip.
>
> Size of entire tzdb database in binary (TZif) form in traditional 
> form: 456 kB uncompressed, 152 kB tar+gzip, 68 kB tar+lzip. This 
> includes all time zone history but omits version info and legal notices.
>
> Same size, but with zic's new '-b slim' option that relies on Internet 
> RFC 8536 instead of attempting to work around bugs in older 
> applications: 216 kB uncompressed, 77 kB tar+gzip, 43 kB tar+lzip.
>
> I don't know how to compute the size of tzdb converted into iCalendar 
> form, but my guess is that it'd be the same order-of-magnitude as the 
> TZif files.


My current set of iCalendar VTIMEZONEs (using symlinks for aliases) is 
also 77kB tar+gz.



>
> All sizes are for ordinary (POSIX) tzdb, not for the rarely-used 
> leapsecond variant.
>
> _______________________________________________
> Tzdist-bis mailing list
> Tzdist-bis at ietf.org
> https://www.ietf.org/mailman/listinfo/tzdist-bis

-- 
Ken Murchison
Cyrus Development Team
Fastmail US LLC

-------------- next part --------------
A non-text attachment was scrubbed...
Name: murch.vcf
Type: text/x-vcard
Size: 4 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/tz/attachments/20190718/367e82db/murch-0001.vcf>


More information about the tz mailing list