Re: install snafu with DT::F::MySQL
On Wed, 7 Jul 2004, Dave Rolsky wrote: > On Wed, 7 Jul 2004, Matt Sisk wrote: > > > I'm having some trouble installing DateTime::Format::MySQL using the > > regular 'cpan' shell (perl -MCPAN -e shell). > > > > I've tried this with both Module::Build versions 0.21 and 0.25. > > > > The install process correctly tracks a dependency on > > DateTime::Format::Builder, but after DT::F::Builder is installed, it > > seems to forget that it was trying to install DT::F::MySQL. So the MySQL > > module never gets installed. > > Ah, right. The problem is that DT::F::Builder includes the DT::F::MySQL > modules under its examples directory, and PAUSE is indexing it. I need to > fix this somehow. I just uploaded new distros of DT::F::Builder & DT::F::MySQL, and that should fix it. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: "localtime" DateTime Objects
On Fri, 2 Jul 2004, Tim Bunce wrote:
> On Thu, Jul 01, 2004 at 07:04:54PM -0500, Dave Rolsky wrote:
> >
> > > I'd also like to see a class based (rather than object based) ability
> > > to set the local time zone, probably through the import:
> > >
> > > use DateTime local => 'Australia/Melbourne';
> > >
> > > Then all constructors would use that as the local (default) zone.
> >
> > Hmm, that's an interesting idea. How about making it something you did
> > with DateTime::TimeZone instead of DateTime?
>
> I think it's dangerous unless it can be lexically scopped (which
> is can't be easily).
>
> It's trvial for an application which wants that behaviour to subclass
> DateTime etc as needed to supply local defaults.
Well, setting the _local_ timezone to some default isn't dangerous. As it
stands, using "local" as the time zone will give you unpredictable
results. On some systems (Win32), we _know_ it will throw an exception
unless $ENV{TZ} is set, because we can't get the time zone from the OS.
So no CPAN module should _ever_ be using this at all. It's really
provided for users who know exactly where there code will be deployed.
For example, if you're writing code that will be deployed across a set of
servers your company controls around the world, you can safely use this if
you are sure that the time zone is set properly on all of them.
I should probably document this more completely.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Re: install snafu with DT::F::MySQL
> Ah, right. The problem is that DT::F::Builder includes the > DT::F::MySQLmodules under its examples directory, and PAUSE is > indexing it. I need to fix this somehow. Why not just bundle them together? CPAN will figure out which bundle to grab when you request a specific module such as DT::F::MySQL. (this only works if you're the maintainer of all modules in question...but I can imagine a scenario where you're bundling someone else's module in your examples directory and messing up their cpanitude...whoops) Matt
Re: install snafu with DT::F::MySQL
On Wed, 7 Jul 2004, Matt Sisk wrote: > > Ah, right. The problem is that DT::F::Builder includes the > > DT::F::MySQLmodules under its examples directory, and PAUSE is > > indexing it. I need to fix this somehow. > > Why not just bundle them together? CPAN will figure out which bundle to > grab when you request a specific module such as DT::F::MySQL. (this only > works if you're the maintainer of all modules in question...but I can > imagine a scenario where you're bundling someone else's module in your > examples directory and messing up their cpanitude...whoops) Well, this would just get confusing, because people who only need DT::F::MySQL would then have to remember to look at new DT::F::Builder releases to see what changed. I don't think bundling basically unrelated modules is really helpful. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
