Are these limitations in the mod.sources time zone stuff worth worry?
Wed Jul 13 23:14:41 UTC 2011
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.
More information about the tz