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

[Paul Eggert <[e-mail]>]

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.

All sizes are for ordinary (POSIX) tzdb, not for the rarely-used leapsecond variant.