Are these limitations in the mod.sources time zone stuff worth worry?

Completely off the standardization track for a moment. . .

There are some limitations in the time zone stuff that was recently posted
to mod.sources; I'm wondering if other folks have opinions on whether the
limitations are worth worrying about, or if folks have inspired changes
to the code that will get around the limitations.  If you're not the
nit-picking type, please feel free to ignore this letter.

A preamble:  the format of the files stored in the /etc/zoneinfo directory
was designed to keep the files small and thus to keep down the overhead involved
in reading the time zone information from disk.  For example, here on Elsie,
the "/etc/zoneinfo/US/Eastern" file weighs in at 814 bytes,
which means that the time zone information fits in one logical disk block.

And now. . .

1.	While the file format allows big-endian and little-endian machines
	to use the same (file-server-provided) file to get time zone information
	from, it can't be used both by (traditional) machines that want to have
	signed time_t's and by (kre-controlled Australian) machines that want
	to have unsigned time_t's.  Is this worth worrying about?  Should the
	transition times be stored as "long long"s, doubles, or text?
	Does the added utility warrant the extra storage?

2.	There are all those nasty "MAX"es built in to tzfile.h (and, by
	reference, into localtime et al.):

#define TZ_MAX_TIMES	370	/* Maximum number of transition times */
#define TZ_MAX_TYPES	10	/* Maximum number of local time types */
#define TZ_MAX_CHARS	50	/* Maximum number of abbreviation characters */

	Are the limits worth worrying about?  Should localtime et al.
	do memory allocation to overcome the limits?  Should the functions
	buffer some of the time zone informtion and go to disk if information
	that's needed isn't in the buffer?

3.	And then there's Saudi Arabia.  (I trust folks saw the recent
	Scientific American article on newly available digital watches that,
	when fed longitude and latitude, will provide local solar time--
	this allows Moslems to observe daily prayers.)  To do Saudi Arabia
	right--or at any rate, to do it right to the second--you need about
	2000 local time types.  Since, these days, local time types are
	stored on disk as unsigned chars, you can only get 256.  The easy
	way out would be to encode time types the same way that transition
	times are encoded; this would about double the size of time zone
	information files.  Is the added functionality worth the size doubling?
	Is the problem even worth worrying about?  Is there a better way to
	deal with it?
--
	UUCP: ..seismo!elsie!ado    ARPA: elsie!ado at seismo.ARPA
	Elsie and Ado are trademarks of Borden, Inc. and Ampex.