Re: Re: [rfc] HiRes
On Sat, 9 Aug 2003, Joshua Hoblitt wrote: > > On the one hand, I agree. "HiRes" is bad, and "hires" is a bit worse. > > OTOH, _so_ many people are already familiar with Time::HiRes, that having > > our own variation on it may be confusing to as many people, or more, as > > "hires" is. > > So are we back to DT::HiRes? Or just rename the constructor? I would > like to see this functionality make it into the next release. I guess sticking it in a separate module DateTime::HiRes works, since that way we don't force people to load Time::HiRes if they don't need it. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DT::F::Strptime dependency in DT::Builder
> : I was recently doing lots of virgin builds and noticed a faulty > : dependency being triggered: > : DateTime::Format::Builder -> DT::F::Strptime -> DT::Language > : > : This fails since some of those are no longer on CPAN. > > Yes, and therefore also breaks the beta version of Time::Piece because > of its reliance on DT::F::Strptime. Hi Rick, I sent you a patch that fixes this sometime ago. I believe you were still having e-mail troubles at the time. Did you receive it? Should I resend it? -J --
Re: DT::TZ test failure
On Sat, 9 Aug 2003, Joshua Hoblitt wrote: > I'm getting this failure from the CPAN dist and when I parse the Olson files myself. > Since 0.25 installed for me without errors at some point in the past I'm assuming > that this failure is being caused by a recent release of DT. Can anyone reproduce > this? > > # This is to check a bug in DT::TZ::_span_for_datetime, where it > # was always looking at the LOCAL_END of the current max_span. > # > # Australia/Sydney's max_span (before generation) has a LOCAL_END > # of 63518522400 and UTC_END of 63518486400. The values above > # create a utc_rd_seconds value that is after the UTC_END but > # before the LOCAL_END. > my $dt = DateTime->from_object( object => TestHack->new ); > > eval { $dt->set_time_zone( 'Australia/Sydney' ) }; > ok( ! $@, 'should be able to set time zone' ); > 161 ok( $dt->is_dst, 'is_dst should be true' ); DateTime.pm now sets the time zone to floating when it creates an object in the from_object() method. I think it used to be UTC. I'll release a new DT::TZ to handle this. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: DateTime->localtime() (was Re: DT::TZ test failure)
On Sunday, August 10, 2003, at 10:24 PM, David Wheeler wrote: On Sunday, August 10, 2003, at 07:17 PM, John Siracusa wrote: Obviously, you need currying. See Perl 6. Or create your own subclass with its own now() method that passes the argument for you. Or create a function that calls it for you, passing your default arguments, and returning the result. In fact, make it a code reference, and you will for all practical purposes have a curried version of the constructor! "Easy things should be easy"^H^Hier than that ;) I think it might have been easier than writing all the email you've sent to the list the last few days. ;-) Like everyone else on this list, I'm sacrificing for all the other Joe Programmers out there ;) -John
Re: RFC: DateTime::TimeZone::LMT
On Tue, Aug 12, 2003 at 08:02:02AM +1000, Rick Measham wrote: What do people think? I can provide patches for this if I'm not the only one who'd find it useful. Ben replied: No, I would like this too. Perhaps the functionality can be rolled into DT::Alias somehow. They seem related... Nah, it has to be a patch on the main DateTime::TimeZone modules. They need to be altered to set the name on objects to the name provided. Maybe there should be an extra accessor ->link_name. (They're called links in the TimeZone innards). Then when ->time_zone_short_name is called and it has no value, it return ->link_name. Same for long_name. Cheers! Rick -- There are 10 kinds of people: those that understand binary, and those that don't. The day Microsoft makes something that doesn't suck is the day they start selling vacuum cleaners "Write a wise proverb and your name will live forever." -- Anonymous
Re: Get the right C compiler?
* Dave Rolsky ([EMAIL PROTECTED]) [10 Aug 2003 00:38]: > On Sat, 9 Aug 2003, Iain Truskett wrote: > > This make sense? make's default $(CC) may have no relation to > > the one Perl was compiled with, so shouldn't we use what > > knowledge we can get? > > > > > > Index: Makefile.PL > > === > > RCS file: /cvsroot/perl-date-time/modules/DateTime.pm/Makefile.PL,v > > retrieving revision 1.31 > > diff -u -r1.31 Makefile.PL > > --- Makefile.PL 24 Jul 2003 03:54:50 - 1.31 > > +++ Makefile.PL 9 Aug 2003 13:13:55 - > > @@ -31,7 +31,7 @@ > > close F or no_cc(); > > > > my $make = $^O =~ /win32/i ? 'nmake' : 'make'; > > -system("$make test$Config{obj_ext}") and no_cc(); > > +system("CC=$Config{cc} $make test$Config{obj_ext}") and no_cc(); > > > > if ( -d 'CVS' ) > > { > Will this match what MakeMaker generates? If so, good, if not, the patch > won't achieve much. Good question. Not sure. At the very least it means it gets it correct for one Solaris box I have access to. It has a perl that was compiled with gcc, but the system default is cc. They are incompatible compilers and with the patch Makefile.PL correctly finds out that a suitable compiler isn't available. cc does exist, but is wrong. If it's not what MakeMaker generates, it's at least *closer* to what MM does. [I've added "research for compiler checking" to my todo list, but there's no guarantee I'll get near it] cheers, -- Iain.