Perhaps I'm not following closely enough, but this thread is confusing me.

On Tuesday, June 17, 2003, at 02:51 PM, Ben Bennett wrote:
On Tue, Jun 17, 2003 at 09:52:46AM -1000, Joshua Hoblitt wrote:
How would an add method that returns silently if an alias is already defined tell if an alias has been redefined somewhere else?
It _only_ returns silently if the current definition matches the
real timezone of the requested definition:
--
my $dta = "DateTime::TimeZone::Alias";
$dta->remove("EST");                    # Start with a clean slate

Clean from what? Is EST already in there? How and why?


$dta->add("EST" => "US/Eastern");       # Succeeds
$dta->add("EST" => "US/Eastern");       # Succeeds
$dta->add("EST" => "America/New_York"); # Succeeds

How is it known that "US/Eastern" "matches the real timezone of the requested definition", "America/New_York"? Is "US/Eastern" also a valid TZ name, like "America/New_York"? Since it's the ALIAS that usually gets bandied about, why would one be changing an alias definition from "US/Eastern" to "America/New_York" if they really stand for the the same underlying time zone?


$dta->add("EST" => "America/Chicago"); # Fails

Is this failing because the string "America/Chicago" is different from the string "America/New_York"? Rather, I hope it's because DT::TZ::A looks up each proposed definition...


I'd be wary of any aliasing system that knows what's best.

What if my program allows a continuous NOW time zone for fast-traveling users, who only need to know or record time as 2003-06-17T16:20:00 NOW. The program re-sets the NOW alias at each airport, or by checking global position, or star light, or ..., so the traveler always functions in local time and her logs are always correct with respect to home or UTC. As I understand this thread, I couldn't redefine an alias once it's (correctly) defined, right? Why use add() and remove() instead of set()?


- Bruce


__bruce__van_allen__santa_cruz__ca__



Reply via email to