Re: best way to to make an easy to use "local" DateTime object?

On 10/01/2012 12:04 PM, Zefram wrote:
> Mark Stosberg wrote:
>> It seems like a useful alternate design might be add this class method:
>>
>> DateTime->DefaultTimeZone($tz);
> 
> That would make the "default timezone" a global variable.  If two modules
> in one program both attempt to set it, you lose.  If a module sets it
> and the main program also does, you lose.  So to be safe, you can never
> set this in a reusable module.
> 
> It gets worse.  You're proposing to have this global variable used in
> places that currently use a constant.  Effectively, lots of code that
> currently works fine by relying on the constant would now be reading the
> new variable.  So if your main program sets the variable to any other
> value, and you're using any of the modules already on CPAN that rely on
> the current behaviour, you lose.

Thanks for that feedback. You made a good case against this approach.

> Which timezone a particular DateTime object needs is not so much a
> function of the application it's in, but of the way it's used in its
> immediate surroundings.  There are three main cases, corresponding
> to the timezone designators "UTC" (for an absolute point in time),
> "floating" (for a calendar time in no particular zone), and "local"
> (for describing a point in time to users).  A few applications need to
> use multiple local timezones, due to people crossing localities.
> 
> Each piece of code that generates DateTime objects should know the
> broad purpose of those objects, and hence which kind of timezone they
> should use.  They should generally set the timezone slot explicitly.
> Relying on the "floating" default is acceptable, but being explicit
> about it is better.

So, it sounds like being explicit is the way to go.

The DateTimeX::Local approach would be explicit, while adding another
layer of abstraction. It would be:

 DateTimeX::Local->new;

vs:

 DateTime->new( time_zone => 'local' );

For a project that does a lot of object creation, I the shorthand could
still be nice.

   Mark