On Wed, 26 Feb 2003, Eugene van der Pijll wrote:
> Dave Rolsky schreef:
> > > Solution: either specify 'utc' as the default time_zone in from_object(),
> > > or make 'floating' the default timezone in new().
> >
> > Or make floating the default in from_object.
>
> When converting DateTime -> DateTime, 'utc' makes more sense, as the utc
> rata die and seconds are used. In general, 'floating' could be better,
> as some calendars may not implement timezones, and _utc_rd_values
> returns 'floating' time values.
Hmm, good point. Maybe something like:
my $tz = $object->can('time_zone') ? 'UTC' : 'floating;
???
> > > I strongly suggest the second solution.
> >
> > Why?
>
> > ... While correct datetime math is unexpected
> > for various reason, I'm not sure that's an expectation I want to
> > propogate ;)
>
> I couldn't care less about datetime math. I will be using these modules
> to do _date math_. I don't care about and want to ignore times, seconds,
> leap seconds, timezones, DST and all that. My impression was that you
> meant DateTime to be a replacement for all date and/or time modules?
> That should mean that those people who want to specify only dates
> shouldn't have to specify a timezone to make it work.
>
> How about this example:
>
> $d = DateTime->new( year => 2002, month => 10, day => 24 );
> $d += DateTime::Duration->new( weeks => 1 );
> print $d->ymd, "\n";
>
> This prints 2002-10-30...
That's a good argument.
> > > As an added bonus, changing to 'floating' as default removes the t/05tz
> > > out-of-memory bug. At least for me.
> >
> > Are you using the latest DateTime::TimeZone? I'm pretty sure this is
> > related to bugs in earlier versions, and if not it needs fixing, not
> > workarounds.
>
> DateTime-0.06, DT::TimeZone-0.08:
>
> when $TZ is set to '-0300', '+0300', or 'Foo', there's no problem;
> when $TZ is set to 'America/Chicago' or 'Europe/Amsterdam', t/05tz
> crashes at test 24.
I'll check this out.
> When the default in new() is changed to 'floating', the local timezone
> is obviously no longer important, and everything works OK. I don't know
> why, because 05tz uses a timezone in the call to new(). It seems like
> you create another DateTime object somewhere while not taking good care
> to specify a timezone.
>
> It seens that the way it is now encourages subtle bugs in the rest of
> DateTime, which are dependent on the users' environment and therefore
> hard to find...
Well, the bugs exist whether or not they're exposed by implementation
details, so they need fixing. But your arguments for defaulting to UTC or
floating are good ones.
-dave
/*=======================
House Absolute Consulting
www.houseabsolute.com
=======================*/
