> Is it a problem that it affects the TZ behavior across all modules? I
I should document this better.
> am not sure how you would get around that with the current TZ
> interface (you would need some way to get a "TZ factory" object that
> you would use as a parameter to DT... but then anything trying to make
> a DT internally would need the factory and that gets nasty).
I'm not convinced that there is anything wrong with current behavior. Although I'm
not sure I understand what your proposing here.
> I 'spose that the current way makes a lot of sense as long as people
> don't overwrite existing items. Perhaps it would be nice to provide a
> way to test if a given alias is defined (and get the value) (although
> I guess DT::TZ::links gives you that, maybe just mentioning it in the
> pod is enough). It may also be nice (but probably overkill) to have a
> method that does a conditional set, so you can choose to say:
>
> DT::TZ::Alias->add("GMT" => "America/New_York")
> or die "Error: tried to overwrite existing TZ alias...";
I can see why this would be useful however...
While the short circuit behavior is nice here what if someone does:
DT::TZ::Alias->add( 'foo' => 'bar' );
And 'foo' already existed. It would quietly die and the programmer would be pretty
baffled as to the problem. cluck or croak is more likely the correct behavior.
That said I'll add a method that checks if an alias and/or a TZ definition exists
before making an alias in the next release (well the release after next, 0.02 is going
to be a bug fix).
Good idea.
> Intenally add would do a set with the rules that if the alias existed
> and had a different value from the new one _or_ the new alias name was
> one of the base timezones then it would throw an error.
>
> What happens if I try to alias EST to US/Eastern? Will that work?
> (i.e. what if I alias to an existing alias?)
This is already planned for the next release. :) Expect something in the next couple
of days.
> My above proposal doesn't correctly handle removing an alias... for
> instance if I have:
> ---
> package Foo;
>
> DT::TZ::Alias->add(EST => 'US/Eastern');
>
> bar();
This should be Bar::Bar() as Bar() isn't defined in this package.
> my $dt = DateTime->now(time_zone => 'EST');
> # ERROR, EST is gone...
I see what your saying although this exactly what I would expect it to do. I'm not
everybody though so I'll try to document a warning about this.
> package Bar;
>
> sub bar {
> DT::TZ::Alias->add(EST => 'US/Eastern');
>
> # stuff
> DT::TZ::Alias->delete('EST');
This should be ->remove
> }
> ---
>
> On the other hand, perhaps people shouldn't clean up stuff. Otherwise
> you have to start tracking which package added what and not actually
> doing the deletion unless all calling packages call
> remove(*)... except when you really want to do the deletion from
> another package for a good reason. I think that way lies madness.
>
> (Or whatever the analog of add would be)
Well you could get the illusion of scoping by wrapping DT with an object that's
DESTROY handler cleaned up after itself but this would be messy. Not to mention I
actually like the global behavior. :)
Cheers,
-J
--
