Re: DT::Wrapper API/semantics

2003-08-14 Thread Dave Rolsky
On Fri, 8 Aug 2003, Flavio S. Glock wrote: Dave Rolsky wrote: Anyway, does this API sound sane? And if it does, anyone have any really clever implementation ideas? I have some scary ones involved AUTOLOAD and constructing classes on the fly. help me understand it - Does something

Re: DateTime used with Class::DBI

2003-08-14 Thread Jean Forget
Answering to Rick Measham (Fri, 8 Aug 2003 10:29:08 +1000) At 4:13 PM -0700 7/8/03, Matthew McGillis wrote: [snip] Casey offers a better solution for the problem you describe, however you *could* (as apposed to should) also do the following (not the safest thing to do, but it works): In your

ANNOUNCE: DateTime 0.1601

2003-08-14 Thread Dave Rolsky
0.1601 2003-08-07 [ BUG FIXES ] - On platforms like Win32, where we can't find a finite() or isfinite() function/macro, the DateTime::LeapSecond code wasn't being loaded, so many tests failed. Reported by Ron Hill. Thanks, Ron. -dave /*=== House Absolute Consulting

Get the right C compiler?

2003-08-14 Thread Iain Truskett
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

DateTime used with Class::DBI

2003-08-14 Thread Matthew McGillis
I'm not sure anyone is interested but I thought I would pass this along. I have started using Class::DBI and was hoping I could also use DateTime with it. Class::DBI has some hooks to allow for any type of Object to represent Time. However the one limitation it has is that you must be able to

RE: Get the right C compiler?

2003-08-14 Thread Hill, Ronald
Hi Iain. * 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? [snipped] Good question.

Re: RFC: DateTime::TimeZone::LMT

2003-08-14 Thread Dave Rolsky
On Thu, 14 Aug 2003, Sam Vilain wrote: A good point. This is needed so that when we serialize DateTime objects, we don't need to serialize the timezone object too. A good point - are you providing these methods for some of those `other' :) persistence tools ? Storable:

Re: DateTime-localtime()

2003-08-14 Thread John Siracusa
On Sunday, August 10, 2003, at 08:59 PM, Joshua Hoblitt wrote: If you only have a year and day of year, then having a from_day_of_year constructor saves a _lot_ of calculation that end users have to do. OTOH, having to do 'DateTime-now(time_zone = local)' isn't very onerous at all. If you need

Re: DT::TZ test failure

2003-08-14 Thread Joshua Hoblitt
Okay, so maybe a new constructor then? DateTime-localtime()? Getting the current local time seems more common than, say, constructing a DateTime object from a day of the year, IMO :) We have enough constructors as it is. I could be talked into: DateTime-now( time_zone = 'local' ); But

Re: RFC: DateTime::TimeZone::LMT

2003-08-14 Thread Joshua Hoblitt
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. I don't like that at all. You really should be creating new classes with your specified

Re: leap seconds in XS

2003-08-14 Thread Dave Rolsky
On Wed, 6 Aug 2003, Dave Rolsky wrote: I just checked this in, but I'm not sure if it's much faster. It'd be good if someone who knows more about about C could look at the implementation and see if there's anything they can think of to improve it. Also, I should probably change the

ANNOUNCE: DateTime::Format::Builder 0.76

2003-08-14 Thread Iain Truskett
Changes for 0.76 (10 Aug 2003) - Fallthrough example and test added. - Quick parser added to simplify fallthrough stuff. - Rejigged internals to allow for on_fail argument to multi-parsers. cheers, -- Iain. pgp0.pgp Description: PGP signature

Re: RFC: DateTime::TimeZone::LMT

2003-08-14 Thread Dave Rolsky
On Mon, 12 Aug 2003, Rick Measham wrote: Attached is the above module. Unless there's strenuous objections I'll CPAN it. I just wish for this and for ::Alias that we could hook in better without messing with the internals. While I'm thinking of it, I'd like to be able to set names and

[patch] use DT in Astro::Sunrise

2003-08-14 Thread Joshua Hoblitt
Hi Ron, Here is a 'eating our own dog food' patch against Astro::Sunrise 0.8. :) Cheers, -J -- diff -ur Astro-Sunrise-0.8/Makefile.PL Astro-Sunrise-0.8.new/Makefile.PL --- Astro-Sunrise-0.8/Makefile.PL 2003-02-27 05:05:20.0 -1000 +++ Astro-Sunrise-0.8.new/Makefile.PL 2003-08-06

Re: DT::TZ test failure

2003-08-14 Thread John Siracusa
On Sunday, August 10, 2003, at 01:34 PM, Dave Rolsky wrote: On Sun, 10 Aug 2003, John Siracusa wrote: ...speaking of which, is there any chance DateTime-now() can be changed to default to the local time zone? It seems to me that now probably means now, here most of the time. I don't have a

Re: DateTime-localtime() (was Re: DT::TZ test failure)

2003-08-14 Thread Joshua Hoblitt
I think a constructor aimed at time_zone = 'local' makes sense. If not that, then perhaps a class variable for DEFAULT_TIMEZONE or somesuch. DateTime-now( time_zone = 'local' ); vs. DateTime-local_now; Saves an incredible 18 characters even with generous spacing. Also, regarding the issue of

Re: RFC: DateTime::TimeZone::LMT

2003-08-14 Thread Sam Vilain
A good point. This is needed so that when we serialize DateTime objects, we don't need to serialize the timezone object too. A good point - are you providing these methods for some of those `other' :) persistence tools ? Storable: $dt-STORABLE_freeze $dt-STORABLE_thaw Pixie:

Re: DateTime-localtime() (was Re: DT::TZ test failure)

2003-08-14 Thread John Siracusa
On Sunday, August 10, 2003, at 09:40 PM, Dave Rolsky wrote: ...unless that's the only way you will *ever* call now()! :) Seriously, who is calling now() *without* time_zone = 'local' arguments? I haven't done so yet, and would like to hear some examples of this usage. Me, because I know that

Re: RFC: DateTime::TimeZone::LMT

2003-08-14 Thread Dave Rolsky
On Tue, 12 Aug 2003, Claus Färber wrote: Rick Measham [EMAIL PROTECTED] schrieb/wrote: While I'm thinking of it, I'd like to be able to set names and short-names for offsets. For short names, that might be a good idea. But for long names, it would break this: | name | Returns the name

Re: RFC: DateTime::TimeZone::LMT

2003-08-14 Thread Rick Measham
On Tue, 2003-08-12 at 07:11, Joshua Hoblitt wrote: While I'm thinking of it, I'd like to be able to set names and short-names for offsets. I have a list of short names in Strptime, but I've love to be able to get these back from TimeZone somehow. Just like we do with Olsen (or is it Olson,

Re: RFC: DateTime::TimeZone::LMT

2003-08-14 Thread Joshua Hoblitt
What I want is the reverse of what alias does. Or rather I'd like timezone to remember what value it was created with. If I create an alias 'EST' = 'UTC' and then create a datetime with 'EST', I'd like to get EST as the name rather than UTC. Awww - I understand what your asking for now. We

Re: RFC: DateTime::TimeZone::LMT

2003-08-14 Thread Ben Bennett
No, I would like this too. Perhaps the functionality can be rolled into DT::Alias somehow. They seem related... -ben 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

Re: DT::TZ test failure

2003-08-14 Thread Joshua Hoblitt
If you only have a year and day of year, then having a from_day_of_year constructor saves a _lot_ of calculation that end users have to do. OTOH, having to do 'DateTime-now(time_zone = local)' isn't very onerous at all. If you need an example DT::F::ISO8601 makes heavy use of

Re: DateTime-localtime() (was Re: DT::TZ test failure)

2003-08-14 Thread Dave Rolsky
On Sun, 10 Aug 2003, John Siracusa wrote: If you only have a year and day of year, then having a from_day_of_year constructor saves a _lot_ of calculation that end users have to do. OTOH, having to do 'DateTime-now(time_zone = local)' isn't very onerous at all. ...unless that's the

Re: Re: [rfc] HiRes

2003-08-14 Thread Joshua Hoblitt
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. What about

RFC: DateTime::TimeZone::LMT

2003-08-14 Thread Rick Measham
Attached is the above module. Unless there's strenuous objections I'll CPAN it. I just wish for this and for ::Alias that we could hook in better without messing with the internals. While I'm thinking of it, I'd like to be able to set names and short-names for offsets. I have a list of short

Re: DT::TZ test failure

2003-08-14 Thread Joshua Hoblitt
DateTime-now( time_zone = 'local' ); It already works this way. See what happens when I read my email before morning coffee. :) -J --

Re: leap seconds in XS

2003-08-14 Thread Flavio S. Glock
Dave Rolsky wrote: Ok, I did some benchmarks and it looks like date math involving leap seconds (basically an DateTime object where the time zone is _not_ floating) has sped up about 10% or so, which is definitely a good thing. How about moving the pure-Perl DT::LeapSecond to DateTime.pm/ ?

Re: leap seconds in XS

2003-08-14 Thread Joshua Hoblitt
How about moving the pure-Perl DT::LeapSecond to DateTime.pm/ ? Seems like a good idea. Do you want to do it or should I? I'd like to keep it separated. I believe it maybe useful outside the context of DT. -J --

Re: RFC: DateTime::TimeZone::LMT

2003-08-14 Thread Claus Färber
Rick Measham [EMAIL PROTECTED] schrieb/wrote: While I'm thinking of it, I'd like to be able to set names and short-names for offsets. For short names, that might be a good idea. But for long names, it would break this: | name | Returns the name of the time zone. If this value is passed to