kre@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@crd.ge.com P. O. Box 8, Bldg. K-1, Rm. 5B36A Schenectady, New York 12301-0008 USA