If you wanted to avoid the up-front cost, as well as the cost of unique key generation at compile/runtime, another option would be to have the program that generates the modules from Olson data pre-generate unique keys for each span. Then have a 'status' hash in each TZ-specific module that informs whether the module-specific spans have been inflated or not. If not, inflate them and store them in the common pool. Spans on demand, and only at the cost of a small list of unique keys in each TZ module.
I forgot to add...the structure of each span would obviously have to be stored somewhere. __DATA__ might not suffice since it takes up memory, but perhaps a flat text file containing all spans would suffice. Then the unique keys could simply be the offsets into that file.
Matt
