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

Steve Crocker steve at shinkuro.com
Thu Jul 18 20:30:08 UTC 2019


Paul and Ken,

Thanks for these estimates.

It doesn’t seem to me the legal verbiage would be part of the regular download, so that would reduce the payload a bit.

Steve

Sent from my iPhone

> On Jul 18, 2019, at 4:26 PM, Ken Murchison <murch at fastmail.com> wrote:
> 
> 
>> 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
> 
> <murch.vcf>


More information about the tz mailing list