[prev in list] [next in list] [prev in thread] [next in thread] 

List:       perl-datetime
Subject:    Re: "localtime" DateTime Objects
From:       Dave Rolsky <autarch () urth ! org>
Date:       2004-07-07 16:34:22
Message-ID: Pine.LNX.4.58.0407071132060.4578 () urth ! org
[Download RAW message or body]

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
=======================*/
[prev in list] [next in list] [prev in thread] [next in thread]