<...> > > Having a look at the code, I noticed that each timezone has it's own class, > > and also a lot of data in perl structures. I'm not really sure why the > > timezone classes were developed this way, it seems fine for a simple case > > where you only need a couple of timezones, but in a case where you can > > possibly be using ANY timezone in the same script, it seems a HUGE overhead > > in memory and time to have to load all those structures into memory. > > Patches welcome ;)
That's probably how I would have responded too... ;-) <...> > > We're fine using our POSIX solution now, but I thought you folks might be > > interested in this feedback - we chatted about it with Rick Measham at Perl > > Mongers yesterday and he asked if we could provide this summary. It's > > probably a good idea to keep web app developers in mind as you develop the > > DateTime namespace, since it's a place where a lot of date/time calcuations > > in Perl are required. > > I do a heck of a lot of web dev, and I've used DateTime and the time zone > classes without any problems. > > For example, you could just preload the time zones that your current users > are using, which would almost certainly be a small fraction of all > possible zones. > <...> That's OK - we're happy with the solution we are using, and were just trying to give back a bit by providing the feedback. We have users in nearly 200 countries with more all the time, so we there are a lot of modules to preload, and we don't know when starting mod_perl the first time which new countries will be represented in the next batch of signups... The only way really to provide a fast (to initialize, and access) timezone DB is to either provide a DB (e.g. CDB, SDBM, etc) with the module, or have something in the make process that creates such a DB based on the DBM modules available on the user's system (or, as you mentioned, use structs with XS). Regards, Rob
