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.
