Hi
I wanted to try out Flávio Glock's suggestion about SLA calculation and
tried to install DateTime::Set.
It is on Debian Sarge, where the Perl is 5.8.4.
Test 15 (time_zone) prints a zillion lines with
_callback_previous: iterator can't find a previous value, got 2001-12-31
after 2001-12-31
From: Rick Measham [mailto:[EMAIL PROTECTED]
Dan Horne wrote:
Hi, I'm trying to determine the local time on an MS Windows PC, and
would
prefer not to have to explicitly set my timezone. From reading the doco,
it
seems that Datetme is pretty UNIX-specific in how it determines local
I'm getting a failing test on line 318 of t/09changes.t in DateTime::TimeZone;
the line is:
like( $@, qr/Invalid local time .+/, 'exception for invalid time
produced via add' );
and $@ is not being set to anything.
This is with DateTime 0.2901; it doesn't seem to fail with 0.28.
The
Just a note -- DateTime::TimeZone appears to, with DateTime 0.29
installed, fail the test on line 318 of 09changes.t,
like( $@, qr/Invalid local time .+/, 'exception for invalid
time produced via add' );
($@ is not set)
Presumably this is related to the only entry in the 0.29
On Tue, 16 Aug 2005, Dan Horne wrote:
Alas, I was hoping that somehow local would just read the time set on the
clock rather than erroring. Thanks Rick,
You can get that from this:
my $dt = DateTime-now( time_zone = $my_time_zone );
So if you explicitly give it the time zone it'll give
On Mon, 15 Aug 2005, Dave Glasser wrote:
I'm getting a failing test on line 318 of t/09changes.t in DateTime::TimeZone;
the line is:
like( $@, qr/Invalid local time .+/, 'exception for invalid time
produced via add' );
and $@ is not being set to anything.
This is with DateTime
So it turns out that DT.pm has basically been buggy with regards to date
math for any timezone with a DST change basically forever.
The problem is that sometimes people want to do math in terms of the local
time (the clock display time) and sometimes in terms of UTC time (the
actual passing
On 8/16/05, Dave Rolsky [EMAIL PROTECTED] wrote:
So it turns out that DT.pm has basically been buggy with regards to date
math for any timezone with a DST change basically forever.
The problem is that sometimes people want to do math in terms of the local
time (the clock display time) and
Dave Rolsky schreef:
But in fact, one hour less than 6 months has passed because of the DST
change
I think this is a very strange thing to say, as the duration 6 months
is never a fixed amount of hours, not even in UTC.
In this case, we added 6 months to the _UTC_ time and the displayed
John Siracusa schreef:
Any chance of the great dates without times vs. datetimes split happening
in DateTime for Perl 5? That'd solve a lot of problems too. Maybe some of
the DateTime::Incomplete stuff could help here?
Dave, are you working on this for Perl 5? I've thought about this as
On Tue, 16 Aug 2005, Eugene van der Pijll wrote:
John Siracusa schreef:
Any chance of the great dates without times vs. datetimes split happening
in DateTime for Perl 5? That'd solve a lot of problems too. Maybe some of
the DateTime::Incomplete stuff could help here?
Dave, are you working
Dave Rolsky schreef:
There have been several reports, they're in the list archives. One was
from Mike Schilli. Then another more recent one complained about the
change I made based on Mike's bug report. Can't win ;)
I've found it now: http://www.nntp.perl.org/group/perl.datetime/5619 .
Kaare Rasmussen wrote:
I've tried the debian package of datetime and I've tried from CPAN. I've
also tried to set different TZ values. Does anyone know what the problem
can be?
This looks like it will be the same problem in the last three or four
threads in the mailing list: the calucation
John Siracusa wrote:
As for the particular proposed changes, I think the methods names don't
clearly describe what's going on. When I see subtract_datetime_utc() I
wonder if I have to pass a DateTime object with its timezone set to UTC or
something.
As I understand it, the distinction is
While Dave's thinking about date math, can I go back a while ...
.. we were talking about method bload in DT. Since then we seem to have
added a new routing for bringing in a default DateTime::Format module too.
.. to combat this, I looked at Dave's Class::ClassDecorator and released
a
use DateTime::Decorated
with = [
'strftime',
# Yes, pull it out of DT and put it in
# DT:Format:Strftime and DT:Decorated:Strftime
'strptime',
# DT:Decorated:Strptime is an accessor interface to DT:F:Strp
'common',
# This will have
Daisuke Maki wrote:
I actually would rather see an mod_perl-style 'add if requested' style.
use DateTime; # load just the basics
use DateTime::Format qw(strftime strptime hms);
# maybe use DateTime::Format qw(:common) ?
my $dt = DateTime-now;
print $dtd-hms;
At least, I don't
On 8/16/05 8:01 PM, Rick Measham wrote:
add_calendar() (aliased to add()) sounds like a good name for the old
behaviour (local for ymd, UTC for hmsn) as we're adding according the
the calender.
I was thinking add_calendar() would be local for ymd and hmsn...but maybe
I'm confused. Basically,
On 8/16/05 8:14 PM, Rick Measham wrote:
I'd like to hear comment on stripping out lots of the methods currently
in DateTime and have them moved to decorator modules -- as this will
allow users to load what they want and only what they want in the way of
functionality.
Fine with me, as long as
I'm cool with that .. I guess then that each Format module that is
'use'd would somehow publish methods to the DateTime Class rather than
an object? I'm not sure how this would be technically done using your
example code ..
Ah, bad naming. I wasn't trying to mix DT::F modules here. How bout
20 matches
Mail list logo
