On Sat, 22 Mar 2003, Rick Measham wrote:
> While I know that DateTime::Astro::Sunrise has been released, I wonder if it
> should not have been DateTime::Set::Sunrise?
>
> I figure that it is a set of DateTimes, albeit not like our regular sets
> (every Monday). If not DateTime::Set::Sunrise, then
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, 21 Mar 2003, fglock wrote:
> Is it ok to have a "to_DateTime" function in Date::ICal ?
>
> $dt = $d_ical->to_DateTime()
>
> Such that you can do tricks with non-DateTime modules:
>
> use Date::Passover;
> $dt = passover( 1997 )->to_DateTime;
How about just implementing utc_rd_values
> My general feeling (without looking at the relevant code to closely) is
> that this should go into a MySQL-specific module. The core should be kept
> small and fast (I have no use for MySQL dates and speed is important).
DateTime::Format::MySQL isn't a MySQL specific module? :)
Hello,
up to now, most of the work appears to have gone into the time
scale stuff - providing an API to map various date and time
representations to each other.
I'd like to see another important aspect of calendars (namely
the Gregorian calendar) covered in the DateTime framework, too:
defining
Hi Rick,
>
> While I know that DateTime::Astro::Sunrise has been released,
> I wonder if it
> should not have been DateTime::Set::Sunrise?
Well, it is up to the group. I released this module as a development release
SO,
it should not be a problem with changing the name. BTW, before posting thi
While I know that DateTime::Astro::Sunrise has been released, I wonder if it
should not have been DateTime::Set::Sunrise?
I figure that it is a set of DateTimes, albeit not like our regular sets
(every Monday). If not DateTime::Set::Sunrise, then it should be put
wherever we'll put such things as:
We need some functions to find out what's inside a set, besides the
"iterator".
I think we need at least these, but I'd like if you would suggest more,
and maybe better names:
->is_infinite_set
->is_empty_set
->is_closed_start
->is_closed_end
More options (negative of the above):
->is_
My general feeling (without looking at the relevant code to closely) is
that this should go into a MySQL-specific module. The core should be kept
small and fast (I have no use for MySQL dates and speed is important).
On Fri 2003/03/21 10:38:46 -1000, Joshua Hoblitt <[EMAIL PROTECTED]> writ
es:
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,
> I honestly don't see the point. I'm not trying to write code for use by
> MySQL itself ;) I just want to provide something that makes interfacing
> with MySQL easier.
I often accept input, modify it some how (offsets, etc), and then pass it on to MySQL.
It is totally reasonable to accept the
Dave Rolsky wrote:
> On Fri, 21 Mar 2003, fglock wrote:
> > Dave Rolsky wrote:
> > > You have to run tools/parse_olson in order to generate the individual time
> > > zones modules and DateTime::TimeZoneCatalog.
> > It would be useful if the tests would tell you that, on failure.
> > Or maybe Makefi
Is it ok to have a "to_DateTime" function in Date::ICal ?
$dt = $d_ical->to_DateTime()
Such that you can do tricks with non-DateTime modules:
use Date::Passover;
$dt = passover( 1997 )->to_DateTime;
- Flavio S. Glock
Dave Rolsky wrote:
> > > You should use _rd2ymd and _ymd2rd. These are much faster cause they're
> > > written in C in DateTime.xs.
...
> The thing is that when Date::ICal says jd there it's lying because it
> really produces Rata Die days! In fact, those functions are the same as
> what DateTime
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
On Fri, 21 Mar 2003, fglock wrote:
> Dave Rolsky wrote:
> >
> > On Fri, 21 Mar 2003, fglock wrote:
> >
> > > All methods are DateTime wrappers; all tests pass.
> > > - Thanks to Dave Rolsky for helping with bugs!
> > > - The functions jd2greg(), greg2jd() are still "native".
> >
> > You should use
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
The project is Greymatter, a CGI blogging package that a lot of people run
in a web hosting environment where they can upload files and run perl
scripts, but probably wouldn't be allowed to compile anything, or in many
cases know how to compile something even if they could. And, there are a
few pe
Dave Rolsky wrote:
>
> On Fri, 21 Mar 2003, fglock wrote:
>
> > All methods are DateTime wrappers; all tests pass.
> > - Thanks to Dave Rolsky for helping with bugs!
> > - The functions jd2greg(), greg2jd() are still "native".
>
> You should use _rd2ymd and _ymd2rd. These are much faster cause
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
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.
BTW, I enjoyed your recent perl.com article on dates, but wish you had
mentioned which datetime modules were pure perl and whic
On Fri, 21 Mar 2003, fglock wrote:
> Dave Rolsky wrote:
> > I think the API needs to be simple and encourage simplicity in its use,
> > because this is a complicated area.
>
> Ok. This one is rather simple:
>
> $dt_spanset = $dt_set->to_SpanSet( duration => $dt_one_month );
>
> Converts this DT:
On Thu, 20 Mar 2003 [EMAIL PROTECTED] wrote:
> > > $set1 = DateTime::SpanSet->new(
> > > start_set => $dt_set, end_set => $dt_set );
> > What would this create exactly?
> >
> > For example, if I have two sets, one of which is
> > an infinite recurrence every month starting on
> > January 1,
On Fri, 21 Mar 2003, fglock wrote:
> All methods are DateTime wrappers; all tests pass.
> - Thanks to Dave Rolsky for helping with bugs!
> - The functions jd2greg(), greg2jd() are still "native".
You should use _rd2ymd and _ymd2rd. These are much faster cause they're
written in C in DateTime.xs.
On Thu, 20 Mar 2003, Joshua Hoblitt wrote:
> > Actually, I think maybe a doc patch is in order instead. The goal of the
> > parse_* methods is to parse things returned _by MySQL_ as a result of
> > queries, not to parse any format that MySQL itself might accept.
>
> Aww, thats not the asumption I
All methods are DateTime wrappers; all tests pass.
- Thanks to Dave Rolsky for helping with bugs!
- The functions jd2greg(), greg2jd() are still "native".
- I think jd() and julian() are internals, may I remove them?
- Is it ok to commit this to Reefknot CVS?
http://www.ipct.pucrs.br/flavio/perl/D
Dave Rolsky wrote:
> You have to run tools/parse_olson in order to generate the individual time
> zones modules and DateTime::TimeZoneCatalog.
Oops.
It would be useful if the tests would tell you that, on failure.
Or maybe Makefile.PL would call tools/parse_olson if you asked politely.
- Flavio S
Dave Rolsky wrote:
> I think the API needs to be simple and encourage simplicity in its use,
> because this is a complicated area.
Ok. This one is rather simple:
$dt_spanset = $dt_set->to_SpanSet( duration => $dt_one_month );
Converts this DT::Set
2002-01-01 ,
2003-01-01
to this DT::Sp
28 matches
Mail list logo
