But that only applies when you load _all_ the zones How would these be shared if you only wanted to load 10-20 zones, or even 150 zones? It seems like the overhead of determining what is shared would outweigh the savings.
As we saw in the beginning of this thread, there are some cases out there where people are faced with loading many, if not all, of the modules. This might be a minority of users, but I'd hate to see the problem become an impedement to the adoption of DateTime.
Do you have any idea of how to implement this in a way that doesn't require all the zones to be loaded up front
As for overhead and implementation. Perhaps a BEGIN block in each TZ module could populate the common data structure with each span array. I'm assuming that would be a hash, and the main thing required would be an efficient way to generate a unique key for each span. Then the same block would populate the private module-specific data structure with references to the shared span arrays.
Once the data structure is built (compile time) there should be no further impacts on efficiency, but there is the extra cost of having to generate unique keys for each span at compile time.
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'm probably missing some crucial detail, but on the surface of it I like the smell of the second option since it has virtually no additional performance impact from today's behavior.
Matt
