Greetings,
I'm afraid this log file doesn't contain anything helpful:
Sep 27 09:20:56 MacBook-Pro-2 diagnostics_agent[433] :
Sep 27 09:20:56 MacBook-Pro-2 diagnostics_agent[433] :
Sep 27 09:20:56 MacBook-Pro-2 diagnostics_agent[433] :
Sep 27 09:20:56 MacBook-Pro-2 diagnostics_agent[433] :
Sep 27
Greetings,
What you sent us is the source code of DateTime, while I appreciate your
efforts I'm afraid this is not helpful.
It is odd that your computer is creating this as a "crash log", but this
doesn't give us anything to go on. We need to know what the error was or
some way to generate the e
Greetings,
Could you provide the stacktrace/the contents of the crash log? As well as
any additional information you have (what was the input? What does the
calling code look like? Can you reproduce this issue on demand? etc). The
more you can give us the better!
In a perfect world a failing
Ginger Smith wrote:
Can't locate object method "_calc_utc_rd" via package
"DateTime::Infinite::Future" at C:/Perl/lib/DateTime/Infinite.pm line
54. Compilation failed in require at DateTime.pm line 69. Compilation
failed in require at Bugzilla/Util.pm line 53. BEGIN failed--compilation
aborted
On Tue, Sep 06, 2005 at 09:57:11AM -0500, Dave Rolsky wrote:
> On Mon, 5 Sep 2005, Joshua Hoblitt wrote:
> >If I understand you correctly, your position is that user's will be
> >confused by DST transitions screwing up additions but won't notice the
> >same effect on subtractions?
>
> No, they'll
On Wed, 7 Sep 2005, Rick Measham wrote:
Dave Rolsky wrote:
Having a wiki would make this easier ;) I'll look for a place to set one
up.
I'm happy to host one (something with auth and good perl rendering) at
http://datetime.isite.net.au/ if you'd like.
I realized that datetime.perl.org is
Dave Rolsky wrote:
Having a wiki would make this easier ;) I'll look for a place to set
one up.
I'm happy to host one (something with auth and good perl rendering) at
http://datetime.isite.net.au/ if you'd like.
Cheers!
Rick Measham
On Wed, 7 Sep 2005, Matt Sisk wrote:
Dave Rolsky wrote:
I will make a list of all the problems I've run across so far, along with
examples that demonstrate them. Anyone who can come up with a solution
that handles all of these problems is a far smarter person than I am ;)
It might already
Dave Rolsky wrote:
I will make a list of all the problems I've run across so far, along
with examples that demonstrate them. Anyone who can come up with a
solution that handles all of these problems is a far smarter person
than I am ;)
It might already be out there...but can you wikifi it a
On Wed, 7 Sep 2005 [EMAIL PROTECTED] wrote:
Dave Rolsky said:
The more I think about this the more I'm convinced that the idea of
datetime subtraction producing something other than seconds is a
convenient fiction. Similarly, date subtraction producing something other
than a count of days is f
On Tue, 6 Sep 2005, Joshua Hoblitt wrote:
No, they'll notice, but the workarounds for subtractions are
well-documented.
So why is that better than making subtractions work 'as expected' and
documenting the work arounds for addition?
Because AFAICT subtractions just _cannot_ work as expected.
- Original Message -
From: "Dave Rolsky" <[EMAIL PROTECTED]>
To: "datetime"
Sent: Tuesday, September 06, 2005 4:39 PM
Subject: Re: DateTime.pm 0.30 coming up real soon now
On Tue, 6 Sep 2005, renard wrote:
The results should be obviously "corre
Dave Rolsky said:
> The more I think about this the more I'm convinced that the idea of
> datetime subtraction producing something other than seconds is a
> convenient fiction. Similarly, date subtraction producing something other
> than a count of days is full of potential bugs.
I agree .. let D
On Tue, 6 Sep 2005, renard wrote:
The results should be obviously "correct" and not throw an unexpected curve.
When I find the difference between 2 dates I expect to obtain the same dates
when I add/subract the difference. If I don't then it raises a red flag on
the correctness of adding/
subt
essage -
From: "Dave Rolsky" <[EMAIL PROTECTED]>
To: "datetime"
Sent: Tuesday, September 06, 2005 10:55 AM
Subject: Re: DateTime.pm 0.30 coming up real soon now
On Tue, 6 Sep 2005, Rick Measham wrote:
You always suggest splitting it up into more packages, but that
On Mon, 5 Sep 2005, Joshua Hoblitt wrote:
On Mon, Sep 05, 2005 at 11:49:33PM -0500, Dave Rolsky wrote:
my $dt = DateTime->new( year => 2003, month => 9, time_zone =>
'America/Chicago' );
$dt->add( months => 3 );
Now what do you expect that to produce? I suspect 99% of users expect
that
On Tue, 6 Sep 2005, Rick Measham wrote:
You always suggest splitting it up into more packages, but that doesn't
necessarily help. I think the real problem here is that a lot of people
just want date math, and they don't care about times. The real split
should probably be a date-only module v
On Mon, Sep 05, 2005 at 11:49:33PM -0500, Dave Rolsky wrote:
> my $dt = DateTime->new( year => 2003, month => 9, time_zone =>
> 'America/Chicago' );
> $dt->add( months => 3 );
>
> Now what do you expect that to produce? I suspect 99% of users expect
> that to produce "2003-12-01T00:00:00"
On Mon, Sep 05, 2005 at 03:15:35PM -0500, Dave Rolsky wrote:
> This means that if you do subtract_datetime on two objects you end up with
> this situation:
>
> $dur = $dt2 - $dt1
> $dt1 + $dur != $dt2
> $dt2 - $dur != $dt1
>
> But honestly I don't really think that's a bug, and it's covere
Dave Rolsky wrote:
Yes, _but_ the docs suggest that if you don't like this you probably
wanted _date_ math (not datetime) in the first place, and you can use
delta_md(), which will return 3 months.
Ahh, cool
You always suggest splitting it up into more packages, but that doesn't
necessarily
On Tue, 6 Sep 2005, Dave Rolsky wrote:
Then again, I wonder if durations shouldn't be removed altogether and put
into separate packages that allowed people to choose their math
assumptions.
You always suggest splitting it up into more packages, but that doesn't
necessarily help. I think the
On Mon, 5 Sep 2005, Dave Rolsky wrote:
could not get it to work sanely. I might take another crack at it if others
object, but I think that the current (in repo) behavior is at least
predictable, accurate, and reasonably sane (and documented).
So I started looking at this and remembered why
On Tue, 6 Sep 2005, Rick Measham wrote:
So, assuming America/Chicago: (2003-12-01) - (2003-09-01) will return a
duration representing 2 months, 29 days and 23 hours?
Yes, _but_ the docs suggest that if you don't like this you probably
wanted _date_ math (not datetime) in the first place, and
Dave Rolsky wrote:
This means that if you do subtract_datetime on two objects you end up
with this situation:
$dur = $dt2 - $dt1
$dt1 + $dur != $dt2
$dt2 - $dur != $dt1
So, assuming America/Chicago: (2003-12-01) - (2003-09-01) will return a
duration representing 2 months, 29 days and 2
On Mon, 5 Sep 2005, Joshua Hoblitt wrote:
On Mon, Sep 05, 2005 at 03:15:35PM -0500, Dave Rolsky wrote:
This means that if you do subtract_datetime on two objects you end up with
this situation:
$dur = $dt2 - $dt1
$dt1 + $dur != $dt2
$dt2 - $dur != $dt1
But honestly I don't really think
On Tue, 6 Sep 2005, Rick Measham wrote:
Once 0.30 is out, I'll put some effort into DT:F:D however it won't be this
weekend as my wife has booked a holiday for the weekend and she'll be mildly
annoyed if I work on DateTime :)
Cool, just wanted to give you a heads up that it'd break your code.
Dave Rolsky wrote:
Rick, I took a look at the code where it's failing and I'm not sure I
understand it well enough to fix it. It's definitely related to the
change in subtract_datetime() (forcing UTC) but I'm not sure how to
either fix the code to make the tests pass, or if maybe the tests enc
On Mon, 5 Sep 2005, Dave Rolsky wrote:
I tested the new version with all the Calendar & Event modules in the DT CVS
repo, and they all passed. However, DateTime::Format::Duration from CPAN
does not pass.
Oops, meant to write more.
Rick, I took a look at the code where it's failing and I'm n
On Thu, Jul 21, 2005 at 01:54:30PM +1000, Rick Measham wrote:
> I want to wrap this up and release so there's 24 hours to finalise the
> name. Here's the names I like thus far:
>
> DateTime::LazyInit (from John Siracusa)
> DateTime::Mock (from Joshua Hoblitt)
> DateTime::Diet (original de
DateTime::LazyInit (from John Siracusa) has received the most votes by
far, so I'll go with it. As one respondant put it, it has 'plain spokenness'
DateTime::Diet, the other name to recieve some votes, made me think of
'DateTime::Lite', and it isn't -- it's full-blown DateTime, just not
immedi
On 21 Jul 2005, at 15:51, [EMAIL PROTECTED] wrote:
Quoting Rick Measham <[EMAIL PROTECTED]>:
Joshua Hoblitt wrote:
What about DateTime::Mock? Since that would make it clear that this
isn't /really/ a DT object.
Thanks Joshua,
I want to wrap this up and release so there's 24 hours to f
Quoting Rick Measham <[EMAIL PROTECTED]>:
Joshua Hoblitt wrote:
What about DateTime::Mock? Since that would make it clear that this
isn't /really/ a DT object.
Thanks Joshua,
I want to wrap this up and release so there's 24 hours to finalise the
name. Here's the names I like thus far:
Date
What about DateTime::Mock? Since that would make it clear that this
isn't /really/ a DT object.
-J
--
On Thu, Jul 07, 2005 at 02:12:41PM +1000, Rick Measham wrote:
> Dave Rolsky wrote:
> > DateTime::Shim
> > DateTime::Trampoline
> > DateTime::ThinShim
> > DateTime::Proxy
> > DateTime::Diet
On Thu, 21 Jul 2005, Rick Measham wrote:
Joshua Hoblitt wrote:
What about DateTime::Mock? Since that would make it clear that this
isn't /really/ a DT object.
Thanks Joshua,
I want to wrap this up and release so there's 24 hours to finalise the name.
Here's the names I like thus far:
Dat
Joshua Hoblitt wrote:
What about DateTime::Mock? Since that would make it clear that this
isn't /really/ a DT object.
Thanks Joshua,
I want to wrap this up and release so there's 24 hours to finalise the
name. Here's the names I like thus far:
DateTime::LazyInit (from John Siracusa)
DateTi
On 7/7/05 12:12 AM, Rick Measham wrote:
> Dave Rolsky wrote:
>> DateTime::Shim
>> DateTime::Trampoline
>> DateTime::ThinShim
>> DateTime::Proxy
>> DateTime::Diet - not awful but a little cute, methinks ;)
>
> Of the above, I still like DT:Diet.
>
> If you want something less cute/more s
On Thu, 7 Jul 2005, Rick Measham wrote:
Dave Rolsky wrote:
It has a pretty different API, in that it's new() constructor accepts
anything without validation.
I suppose it could check for extra args and call DateTime::Fat->new() if
needed.
I think that'd be a possibility, but it'd have to p
Dave Rolsky wrote:
It has a pretty different API, in that it's new() constructor accepts
anything without validation.
I suppose it could check for extra args and call DateTime::Fat->new() if
needed.
Can we split the existing new() into validation vs. object creation and share it
between the
Dave Rolsky wrote:
DateTime::Shim
DateTime::Trampoline
DateTime::ThinShim
DateTime::Proxy
DateTime::Diet - not awful but a little cute, methinks ;)
Of the above, I still like DT:Diet.
If you want something less cute/more serious how about:
DateTime::FastConstructor
The others listed
On Wed, 6 Jul 2005, John Peacock wrote:
At the risk of sounding flippant, why not rename the existing DateTime
class to DateTime::Fat (or the less inflamatory DateTime::Base) and
put the proposed module in it's place as DateTime. If it is designed
well, everything should Just Work(TM) with the
On Wed, 6 Jul 2005, John Peacock wrote:
At the risk of sounding flippant, why not rename the existing DateTime class
to DateTime::Fat (or the less inflamatory DateTime::Base) and put the
proposed module in it's place as DateTime. If it is designed well,
everything should Just Work(TM) with th
Dave Rolsky wrote:
It sounded like people were interested. And maybe it's a "if you build
it they will come" thing ;)
Anyway, go for it and let's brainstorm on a better namespace. Here's
some thoughts:
At the risk of sounding flippant, why not rename the existing DateTime class to
DateT
On Thu, 7 Jul 2005, Rick Measham wrote:
So .. would this module actually get used by anyone but me? If so I'll go
ahead and polish it off.
It sounded like people were interested. And maybe it's a "if you build it
they will come" thing ;)
Anyway, go for it and let's brainstorm on a better n
On Wed, 6 Jul 2005, John Siracusa wrote:
If you're going for speed, there's more low-hanging fruit to be had.
Check
out my modifications in DateTime::Diet2 (attached).
Dave Rolsky wrote:
Yeah, I was thinking that we'd do something like this if we're going to
turn this into an officially bles
On Wed, 6 Jul 2005, Eric Cholet wrote:
Have you tried turning off the validation by setting the PERL_NO_VALIDATION
environment variable?
John, thanks for the pointer. I see this is documented in Params::Validate.
I'd never thought of looking in Params::Validate docs to find out how to
disable
On Wed, 6 Jul 2005, John Siracusa wrote:
On 7/5/05, Rick Measham <[EMAIL PROTECTED]> wrote:
DateTime::Diet (attached) is a simple wrapper around DateTime that
handles simple new(), set() and get methods. If you ask it for something
it can't handle by itself, it reblesses your object into full D
On 7/5/05, Rick Measham <[EMAIL PROTECTED]> wrote:
> DateTime::Diet (attached) is a simple wrapper around DateTime that
> handles simple new(), set() and get methods. If you ask it for something
> it can't handle by itself, it reblesses your object into full DateTime
> and then calls the method on
I've used this approach in Date::Set. It runs the same test suite of
DateTime::Event::ICal, in one third of the time.
- Flavio S. Glock
2005/7/6, Rick Measham <[EMAIL PROTECTED]>:
>
> DateTime::Diet (attached) is a simple wrapper around DateTime that
> handles simple new(), set() and get methods
Le 5 juil. 05 à 15:15, John Siracusa a écrit :
On 7/5/05 7:04 AM, Eric Cholet wrote:
A while ago we did some profiling of an app that uses DateTime
extensively and found out that most of the time is spent in
Params::Validate. I understand this is somewhat of a religious issue,
but in this case
> Geoffrey, if you're reading this, I'd love your comments on how useful
> this would be in your case.
I am :)
ok, I haven't looked at the code yet, but from your explanations it sounds
attractive, especially in our situation. just like you, we don't
necessarily need data validation since the d
On 7/5/05 11:09 PM, Rick Measham wrote:
> I have written a module I tentatively call DateTime::Diet that helps
> with this. I use DateTime in all sort of projects including hooks in
> Class::DBI where many many table records all become DateTime objects,
> even if I don't need the column that repres
Dave Rolsky wrote:
I'm not sure what you mean. It's much quicker for operations that occur
before the rebless. If you were to keep using that object for further
operations, the speed increase given from calling one "diet" method
would fade into background noise.
True. I expected a quicker d
On Wed, 6 Jul 2005, Rick Measham wrote:
I've included the output of the attached script below. I was surprised to
note that even after the rebless was included in the tests, the Diet version
was still *much* quicker.
I'm not sure what you mean. It's much quicker for operations that occur
be
Dave Rolsky asked:
The first question to answer is what are people doing with these
objects?
Geoffrey Young wrote:
in our case, creating many, many, many of them. more than you can possibly
imagine. think one object with a few dozen "time" representations held
within it, then a few thousand
On Tue, 5 Jul 2005, Geoffrey Young wrote:
again, not arguing over which is better, but having _all_ the zone data
cached had the appearance of being wasteful for us - for the most part we
would be converting between _maybe_ a dozen time zones tops, more likely
around the 6 or so surrounding the
just FYI, but I tried to champion DateTime during a massive DT rewrite at
work and lost. the biggest gripe was that the objects were "insanely
large". large in terms of memory per object and (more important to them,
apparently) large enough that it made frequent Data::Dumper dumps difficult
to pa
On 7/5/05 7:04 AM, Eric Cholet wrote:
> A while ago we did some profiling of an app that uses DateTime
> extensively and found out that most of the time is spent in
> Params::Validate. I understand this is somewhat of a religious issue,
> but in this case it's a net loss for us: the params have bee
Le 4 juil. 05 à 19:47, Dave Rolsky a écrit :
Well, I'd take Sam's message with a grain of salt. I use it in
lots of projects, and I know it's being used by lots of other
people for lots of things. The idea that it's "too slow" is
bogus. It might be too slow/bulky if you're creating thous
Dave,
I agree about taking it with a grain of salt.
However,
a) it is true that DateTime is slow (compared to other alternatives), and
b) It's just not good that we give people excuse like this to
not to use DateTime or to make it look like DateTime is not up to par
So I think we s
On Mon, 4 Jul 2005, Daisuke Maki wrote:
> I have found DateTime unsuitable to quite a few tasks for
> various unfortunate reasons; which is a shame given the level of
> following and amount of design time that's gone into it.
And I quite agree. It's a shame if we don't fix this and make
Date
* Matt Sisk ([EMAIL PROTECTED]) [13 Apr 2003 11:53]:
[...]
> Are there plans to use the request tracker on CPAN for this kind of
> thing, or this list the appropriate forum for now?
All the modules I've been putting out either just mention rt.cpan.org as
a place to lodge bugs for it, or give a fu
On Sat, 12 Apr 2003, Matt Sisk wrote:
> Are there plans to use the request tracker on CPAN for this kind of thing, or
> this list the appropriate forum for now?
rt.cpan.org is a good place to report bugs, assuming they are actually
bugs ;)
-dave
/*===
House Absolute Consult
> DateTime.pm claims to have a now() method equivalent to from_epoch() -- but
> there is no now().
Scratch that -- I've sorted out my versions now.
I'm still interested in this question, though:
> Are there plans to use the request tracker on CPAN for this kind of thing, or
> this list the appro
63 matches
Mail list logo
