Back-of-the-envelope cost of extra data :-)

[Kevin Kenny]

kre at munnari.oz.au said:
> If at some future point the code is going to switch from the tables,
> to an algorithmic conversion, why bloat the tables by including so
> much speculative future data?

Exactly what I've been saying - except that for some reason my messages
haven't been getting to the mailing list.  I'm perfectly comfortable with
today's tables that go out to Y2038 and resorting to a single rule
for the fictitious timezone that exists thereafter.  (We need to expand
the table format so that as Y2038 approaches, we can extend the data past it,
but that's by no means urgent.)  Really, I find the whole argument
ridiculous.

Incidentally, for whatever it's worth, todays zoneinfo files occupy
about 5.1 megabytes on my Linux box.  The actual data are only about
450 kilobytes; the rest results from internal fragmentation.  A gzip'ped
tarball of the zoneinfo files compresses down to a bit over 250 kilobytes.
(This include the 'right' files; Tcl's selected set compresses to 190
kilobytes, even though its information files are text files. Tcl doesn't
need the 'right' files, ever, because its model of time has no leap
seconds - it's similar to Markus Kuhn's UTS.)

--
73 de ke9tv/2, Kevin KENNY   GE Corporate Research & Development
kennykb at crd.ge.com           P. O. Box 8, Bldg. K-1, Rm. 5B36A
                             Schenectady, New York 12301-0008 USA