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@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@ietf.org https://www.ietf.org/mailman/listinfo/tzdist-bis
-- Ken Murchison Cyrus Development Team Fastmail US LLC
<murch.vcf>