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 test case that reproduces the crash would
>>>> be fantastic, but if that's not possible
crash would be
>> fantastic, but if that's not possible we can get started with a bit more
>> information to help pinpoint the source of the issue.
>>
>> Thanks!
>>
>> Best Regards,
>> Robert Stone
>>
>> On Fri, Dec 2, 2016 at 1:30 AM, M
has been randomly spitting out a crash log from time
> to time, titled "datetime.pm". I took a moment to actually scroll through
> it and it points back to you. What's the deal?
>
> Mason Razavi
> Guitarist, Composer, Educator
> www.masonrazavi.com
> CDBaby <htt
Hi Dave - my computer has been randomly spitting out a crash log from time
to time, titled "datetime.pm". I took a moment to actually scroll through
it and it points back to you. What's the deal?
Mason Razavi
Guitarist, Composer, Educator
www.masonrazavi.com
CDBaby <http://www
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.
ethod "_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 at Bugzilla/Util.pm line
0.4401 2008-11-03
- In order to handle epochs > 2**32 properly on a 32-bit machine, we
also need to import gmtime from Time::y2038. This changes fixes a
whole bunch of test failures seen with 0.44.
-dave
/*
http://VegGuide.org
0.44 2008-11-01
- XS-capable DateTime.pm now uses Time::y2038 instead of
Time::Local. This lets it handle epochs up to 142 million years
before and after the Unix epoch.
- Fixed a compiler warning with Perl 5.10.0.
- Fixed docs for year_with_era, which had AD and BC
backwards. Reported
ave Rolsky [mailto:[EMAIL PROTECTED]
Sent: Friday, September 08, 2006 9:40 AM
To: datetime
Subject: RE: Getting number of days between two dates using DateTime.pm
On Fri, 8 Sep 2006, Loo, Peter # PHX wrote:
> I tried using DateTime.pm, however, it was costing me about 11 seconds
> for every
On Fri, 8 Sep 2006, Loo, Peter # PHX wrote:
I tried using DateTime.pm, however, it was costing me about 11 seconds
for every 5,000 rows so I ended up using Time::Local and the localtime
that came with Perl. Here is my sample code:
If by rows your mean from a DBMS, you'd probably get the
Hi Daisuke,
I tried using DateTime.pm, however, it was costing me about 11 seconds
for every 5,000 rows so I ended up using Time::Local and the localtime
that came with Perl. Here is my sample code:
my ($year, $month, $day) = split('-', $prev[7]);
my $m = $month; $m
Try using DateTime::Format::Duration with the %j pattern
--d
Loo, Peter # PHX wrote:
Hi,
I am trying to obtain number of days difference between two dates. Is
it possible to do this using DateTime.pm? For example:
2006-09-06 - 2006-08-12 = 25 days
The result that I want is 25 days. I
Hi,
I am trying to obtain number of days difference between two dates. Is
it possible to do this using DateTime.pm? For example:
2006-09-06 - 2006-08-12 = 25 days
The result that I want is 25 days. I tried using the
$diff = $dur->in_units( 'days' );
but I am onl
- Removed all uses of UNIVERSAL::isa and UNIVERSAL::can.
Is there a ticket number for this? I'm wondering why...
I should've said "... in favor of calling isa() and can() as methods".
It's just more correct, and lets people use stuff like Test::MockObject
with DateT
eople use stuff like Test::MockObject with
DateTime.pm.
On the other hand its also slower as its resolved at run time not startup
time, and it has cascade all the way up the @ISA first.
I seriously doubt that this change had a major impact on the speed on
DateTime.pm. Benchmarks to the contrar
It's just more correct, and lets people use stuff like Test::MockObject
with DateTime.pm.
-dave
/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg. My book blog
===*/
>- Switched some uses of die() to Carp::croak(), where
Excellent, I've had to add in handlers for $SIG{__DIE__} locally.
Given all its other dependencies, I'd wondered why DT shyed away
from this most useful one ;-)
>- Removed all uses of UNIVERSAL::isa and UNIVERSAL::can.
Is there a ticket number
Nothing too big here, but I had some useful changes sitting in SVN I
thought I might as well release.
0.312006-05-21
[ ENHANCEMENTS ]
- Switched some uses of die() to Carp::croak(), where
appropriate. This should make error messages more useful in many
cases. Based on a suggestion by Max M
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
So I have it to a state where I'm pretty happy with the code and docs. It
won't satisfy everyone, but that's more or less impossible given how many
"correct" ways of doing datetime math I've come up with.
Here's the summary:
- Adding a duration contains to work the same way as it always did,
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
it'd have to pass the DateTime.pm test
suite in that case.
We'd need to bring complete validation back in though. Otherwise your object
dies unexpectedly later on:
$dt = DateTime::Diet->new( year => 2004, month => 232 );
print $dt->year;
#2004
print $dt->month;
#232
s around most of the time, the
performance drain due to validation won't be quite as noticible.
I think that'd be a possibility, but it'd have to pass the DateTime.pm
test suite in that case.
That's certainly where I was considering starting (with the test suite). It
mi
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
ng 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 pass the DateTime.pm
test suite in that case.
We'd need to bring complete validation back in though. Otherwise your
objec
l DateTime::Fat->new() if
needed.
I think that'd be a possibility, but it'd have to pass the DateTime.pm
test suite in that case.
-dave
/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg. My book blog
===*/
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
#x27;t fix this and make
DateTime.pm useful in any project -- and damnit I want to see it
survive in Perl6.
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
ateTime 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
DateTime.pm useful in any project -- and d
On Fri, 6 Aug 2004, Eugene van der Pijll wrote:
> I've attached a patch for the test files. I haven't looked into the
> DateTime.pm code, because both leap second and the time zone handling
> code are just too scary!
I checked this patch in. I'll try t
,
time_zone => '+00:00:30' );
print $dt->iso8601, "\n";
# prints 1997-07-01T23:59:90 !
I've attached a patch for the test files. I haven't looked into the
DateTime.pm code, because both leap second and the time zone handling
code are just too sc
0.2101 2004-06-10
- There was a bug in the date math code that occurred if you tried to
add enough days, minutes or seconds to generate a datetime 10 years in
the future (or so). If the the DateTime object had a a time zone with
recurring DST changes, then the date math operation would cause a
f
Hello,
[snipped]
>
> I'm stumped..
>
> I have a problem installing DateTime.pm. I get a LNK1106 &
> U1077 with the 'nmake' command. The messages for PERL- V and
> 'nmake' are below. I am using Windows XP and VC++ 5
>
> I have plenty of
> Has anyone encountered this problem before? Got a solution?
Is upgrading to Perl 5.8.0 an option for you?
-J
--
I'm stumped..
I have a problem installing DateTime.pm. I get a LNK1106 & U1077 with the 'nmake'
command. The messages for PERL- V and 'nmake' are below. I am using Windows XP and
VC++ 5
I have plenty of available space on my hard drive and there are no integri
0.1703 2003-09-22
- truncate( to => 'week' ) caused a fatal error when the beginning of
the week was in the previous month. Reported by R. Mathews.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
E=1 TEST_FILES=t/...'
> This gives me extra info that makes it easier to track down
> the failures.
OK, I'm sorry about that. I will include this in the future
G:\modules\DateTime.pm>nmake test TEST_VERBOSE=1 TEST_FILES=t/20infinite.t
Microsoft (R) Program Maintenance Utilit
On Tue, 15 Jul 2003, Hill, Ronald wrote:
> Test report for the CVS version of datetime. Is there
> a better place to post test results other than on
> the newsgroup?
Nope, this is good.
> t\13strftime..NOK 41# Failed test (t\13strftime.t at line 44)
> # got: 'Sep 7, 1999 1:0
Hi All,
Test report for the CVS version of datetime. Is there
a better place to post test results other than on
the newsgroup?
Hope this helps.
Ron Hill
[snipped]
t\13strftime..NOK 41# Failed test (t\13strftime.t at line 44)
# got: 'Sep 7, 1999 1:02:42 PM'
# expected:
Any progress on this? If not, I'll probably throw in a hack in the
DateTime.xs to just not compile _normalize_seconds on Win32, because I
really want to make a new release of DateTime.pm, and I don't want to wait
much longer for the Win32 fixes.
-dave
/*===
Hous
* 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,
DateTime.pm claims to have a now() method equivalent to from_epoch() -- but
there is no now().
Are there plans to use the request tracker on CPAN for this kind of thing, or
this list the appropriate forum for now?
(for the record, I like the notion of a now() method)
Thanks,
Matt
On Fri, 21 Mar 2003, Tim Bunce wrote:
> Having transparent failover is handy.
>
> You can wrap the "bootstrap" call in an eval { }. Then you've got
> a few choices, either put the perl versions of the XS subs at the
> end after __DATA__ and add "use SelfLoader;", or do a require of a
> separate mo
On Fri, Mar 21, 2003 at 01:11:04PM -0600, Dave Rolsky wrote:
> On Fri, 21 Mar 2003, fglock wrote:
>
> > Dave Rolsky wrote:
> > > I suppose I could include a pure Perl solution. What is your barrier to
> > > using XS?
> >
> > That's something I'd like too.
> >
> > I could test my code on Windows,
On Fri, 21 Mar 2003, fglock wrote:
> Dave Rolsky wrote:
> > I suppose I could include a pure Perl solution. What is your barrier to
> > using XS?
>
> That's something I'd like too.
>
> I could test my code on Windows, without having to wait until someone
> compiles it for me.
Ok, I'll implement
Dave Rolsky wrote:
> I suppose I could include a pure Perl solution. What is your barrier to
> using XS?
That's something I'd like too.
I could test my code on Windows, without having to wait until someone
compiles it for me.
- Flavio S. Glock
all of its date calculations are done by hand without the benefit
of any of the CPAN solutions. :-(
Wes Sheldahl
Dave Rolsky <[EMAIL PROTECTED]> on 03/21/2003 01:05:46 PM
To:[EMAIL PROTECTED]
cc:datetime <[EMAIL PROTECTED]>
Subject: Re: XS in DateTime.pm
On Fri, 21 Mar
On Fri, 21 Mar 2003 [EMAIL PROTECTED] wrote:
> So is the DateTime suite going to be completely dependent on XS code? If
> so, I have at least one app that will need to stick with Date::PCalc or
> some pure perl solution.
I suppose I could include a pure Perl solution. What is your barrier to
usi
On Thu, 27 Feb 2003, Eric Cholet wrote:
> > - Added support for specifying a language by ISO code ("en" or
> > "pt-br") as well as the subclass name. Based on a patch from Erich
> > Cholet.
>
> Thanks, works great, I was able to switch my app to use DateTime's
> strftime() with languages thanks t
--On Wednesday, February 26, 2003 23:10:58 -0600 Dave Rolsky
<[EMAIL PROTECTED]> wrote:
- Added support for specifying a language by ISO code ("en" or
"pt-br") as well as the subclass name. Based on a patch from Erich
Cholet.
Thanks, works great, I was able to switch my app to use DateTime's
str
0.07
[IMPROVEMENTS]
- Added a small hack to the compare() method so that this module can
be used with Set::Infinite.
- Changed compare so that it can be used to compare two objects from
different calendars that conform to the DateTime::Calendar interface.
- Added explanation of exactly what cal
1 - 100 of 124 matches
Mail list logo
