Re: DateTime setting invalid zone.

[Bill Moseley]

On Wed, Mar 13, 2013 at 9:10 AM, Dave Rolsky auta...@urth.org wrote:

 On Tue, 12 Mar 2013, Bill Moseley wrote:

  So, I found some old that wrapped a set_time_zone in an eval.

 my $dt = DateTime-new(
year = 2013,
month = 3,
day = 10,
hour = 2,
minute = 4,
time_zone = 'floating',
 );

 eval { $dt-set_time_zone( 'America/Los_Angeles' ); };

 print $dt  . $dt-time_zone . \n;


 The code was using the eval to check if the timezone set failed, and if it
 did went on to do something else with $dt (like set to UTC).   But, it
 seems like even if it fails the time zone gets set.  The above returns
 this
 invalid time:

 2013-03-10T02:04:00
 DateTime::TimeZone::America::**Los_Angeles=HASH(**0x7fc4c2aafc90)

 My question is should DateTime associate that timezone to $dt if the
 set_time_zone call actually throws an exception?


 This is almost certainly a bug.


Ok, filed as:

https://rt.cpan.org/Ticket/Display.html?id=83940


Thanks,

-- 
Bill Moseley
mose...@hank.org

Re: DateTime setting invalid zone.

[Dave Rolsky]

On Tue, 12 Mar 2013, Bill Moseley wrote:


So, I found some old that wrapped a set_time_zone in an eval.

my $dt = DateTime-new(
   year = 2013,
   month = 3,
   day = 10,
   hour = 2,
   minute = 4,
   time_zone = 'floating',
);

eval { $dt-set_time_zone( 'America/Los_Angeles' ); };

print $dt  . $dt-time_zone . \n;


The code was using the eval to check if the timezone set failed, and if it
did went on to do something else with $dt (like set to UTC).   But, it
seems like even if it fails the time zone gets set.  The above returns this
invalid time:

2013-03-10T02:04:00
DateTime::TimeZone::America::Los_Angeles=HASH(0x7fc4c2aafc90)

My question is should DateTime associate that timezone to $dt if the
set_time_zone call actually throws an exception?


This is almost certainly a bug.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

Re: DateTime setting invalid zone.

[Mark Stosberg]

On 03/13/2013 12:10 PM, Dave Rolsky wrote:
 On Tue, 12 Mar 2013, Bill Moseley wrote:
 
 So, I found some old that wrapped a set_time_zone in an eval.

 my $dt = DateTime-new(
year = 2013,
month = 3,
day = 10,
hour = 2,
minute = 4,
time_zone = 'floating',
 );

 eval { $dt-set_time_zone( 'America/Los_Angeles' ); };

 print $dt  . $dt-time_zone . \n;


 The code was using the eval to check if the timezone set failed, and
 if it
 did went on to do something else with $dt (like set to UTC).   But, it
 seems like even if it fails the time zone gets set.  The above returns
 this
 invalid time:

 2013-03-10T02:04:00
 DateTime::TimeZone::America::Los_Angeles=HASH(0x7fc4c2aafc90)

 My question is should DateTime associate that timezone to $dt if the
 set_time_zone call actually throws an exception?
 
 This is almost certainly a bug.

Would a fix to first clone the object, attempt to change time zone, and
then only set the timezone on the original object if it succeeds?

   Mark