And to ask a nasty question... will it support localization?
Or I suppose if your mapping is from lat/long to TZ then the localization problem will be in the code for taking a location name and producing the lat/long. Which makes this more tractable.
-ben
Well, I dunno. :-)
Seriously: I was not suggesting that I create code that would actually be released as part of the overall DateTime modules. Frankly, I don't think I'm qualified for that. And I'm certainly not familiar enough with the innards of the modules, or the interactions among them, or every other little detail that goes into this.
But if I have to sit down and compile a table of mappings -- either city->zone or long/lat->zone, or possibly both -- I will be happy to contribute the results of that grunt work to the project in the event that anyone who =is= qualified to write the actual module code wants to do so.
I currently have a database of about 2.7 MILLION world cities with latitude and longitude for each. This could be a gargantuan task, and I'm still not altogether sure of even how to begin. Use political boundaries? Use straight latitude/longitude? Use the Olsen approach of "continent/region"? Use some combination of all these? And how to leave room for updating, when some country splits into three new countries straddling two zones?
I still need to do some homework on this. I'm just hoping I can get my client's project done......
But if a spin-off of that project can make a contribution here as well, I think that would be a Good Thing. And, yes, I think localization will only affect the lookup function itself. All I'm trying to do here is determine the time zone name to use to create the initial DateTime object, given a date, a time, and a specific location. Once you have the zone name to pass to DateTime->new, everything else works as it currently does.
--- Ed
======================== Ed Perrone Interactive Web Development [EMAIL PROTECTED] http://www.edperrone.com ========================
