On Fri, 10 Jan 2003, Matthew Simon Cavalletto wrote:
> > - DateTime::Base [...] A good candidate for this is the existing
> > Date::ICal code, with a bunch of the Time::Piece convenience methods
> > thrown in for good measure.
>
> I'd suggest having an abstract base class one level above the ICal
On Fri, 10 Jan 2003, Matt Sergeant wrote:
> What I want to see is a Time::Piece based on Date::Ical (or if that becomes
> DateTime.pm then fine). I've wanted that since I read the Pod for
> Date::Ical and realised (like David and Dave have) that it's not just for
> the ICal format - it's actually
As a perl user I welcome the effort of standardizing perl dates. It is
basically a good thing to do, I already tried to do such a thing with
Class::Date, and at that time, this module filled a demand for a good OO
date class. This module is used by quite a few users, but I developed it
mostly alone
On Fri, 10 Jan 2003, dLux wrote:
> I have checked the Date::ICal module, which addressed most of the issues
> I have faced in the development of Class::Date. Although it does not
> solve all of this, the module implementation is quite good, ideal for
> a DateTime base class.
I think it certainly
On Fri, 10 Jan 2003, Matt Sergeant wrote:
> Don't throw out the baby with the bathwater. There's some good things
> going for Time::Piece right now:
>
> 1. It has a *lot* of users.
> 2. It has quite a bit of good and mostly reusable code.
> 3. It's the API blessed/designed by Larry Wall (that may
Dave Rolsky wrote:
I don't know why, but it's time to change it.
Good for you! Count me in somewhere between moral support and actually
dedicating myself to coding. ;~) No, seriously, I cannot promise any specific
level of support, but I will be very interested in the API discussion. And th
On Fri, 10 Jan 2003, Matt Sergeant wrote:
> On Fri, 10 Jan 2003, Dave Rolsky wrote:
>
> > This is the reason I want to talk first about the API. That's what is
> > missing. We have lots of great functionality, but every piece has a
> > different, and incompatible, API. That's what sucks!
>
> To
On Fri, 10 Jan 2003, John Peacock wrote:
> > 1. Stop herding cats. If existing module authors don't want to play,
> > then screw them.
>
> One word for you: wrappers. I want to call to your attention the methodology
> pursued by Tels when he rewrote the Math::BigInt/BigFloat core modules. He
>
Dave Rolsky wrote:
- configurability with localizable variables
If you're talking about the stuff in Class::Date like
$Class::Date::RANGE_CHECK, I _really_ dislike this interface. This sort
of stuff should be settable on a per-class and per-object basis, not by
exposing global variables.
Se
> - timezone-handling
Yes, I talked about this. It should use the Olsen database to get _real_
timezone. I don't think it can rely on POSIX stuff since it needs to work
across as many platforms as possible. Jesse Vincent began some code to us
the Olsen db from Perl. It
On Fri, 10 Jan 2003, dLux wrote:
> I disagree with this, because handling these things are not
> object-dependent, but context-dependent. I need to write a function,
> which handles dates in one way, but I don't want to force users of the
> module work dates like this.
>
> When I have a function,
On Fri, 10 Jan 2003, Rich Bowen wrote:
> > [ CC'd to the Mpls Perl Monger list, Matt Sergeant, and David Wheeler, all
> > of whom have expressed some interest in the topic. I'd suggest that
> > further discussion be solely on the [EMAIL PROTECTED] list, however. ]
>
> Thanks, Dave, for doing this
On Fri, 10 Jan 2003, Jean Forget wrote:
> There *is* a difference between Date:: and Time:: namespaces. Date::
> modules do not consider durations less than one day. I did not choose
> at random between Date:: and Time:: for my module, neither did Rich
> Bowen (Discordian), Abigail (Maya), Leo Cac
On Fri, 10 Jan 2003, Stephen R. Wilcoxon wrote:
> On Thu 2003/01/09 16:04:04 CST, Dave Rolsky <[EMAIL PROTECTED]> writes:
>
> > -- Provides simple date parsing ala Time::Piece->strptime. Maybe throw in
> > the functionality provided by Date::Parse? Maybe make this a separate
> > module. Doesn't
On Fri, 10 Jan 2003, Ken Williams wrote:
> Yeah, the base module should accept several different non-ambiguous
> "canonical" formats such as the ones used in RFCs, and things like
> -MM-DD HH:MM:SS. A supplementary module could handle fuzzy stuff
> like "3 days ago" and "a month from tomorrow
On Friday, January 10, 2003, at 11:37 AM, Stephen R. Wilcoxon wrote:
On Thu 2003/01/09 16:04:04 CST, Dave Rolsky <[EMAIL PROTECTED]> writes:
-- Provides simple date parsing ala Time::Piece->strptime. Maybe
throw in
the functionality provided by Date::Parse? Maybe make this a separate
modul
On Fri, 10 Jan 2003, Dave Rolsky wrote:
> > > -- DateTime::Algorithm::Leapyear
> > > -- DateTime::Algorithm::Passover
> >
> > Isn't that DateTime::Event::Passover?
>
> Doh, I'm confusing myself. I think maybe DateTime::Algorithm and
> DateTime::Event have _way_ too much overlap.
>
> I also realiz
On Friday, January 10, 2003, at 02:13 AM, Dave Rolsky wrote:
my $order_d = Date::ICal->new( epoch => time );
printf( '%04d/%02d/%02d', $order_d->year, $order_d->month,
$order_d->day );
my $ship_d = $order_d + Date::ICal::Duration->new( days => 5 );
printf( '%04d/%02d/%02d', $ship_d->year,
On Friday, January 10, 2003, at 01:17 AM, dLux wrote:
- To make it supported by the whole perl community, inclucing module
developers. For example, I want to pass a date object to the DBI
bind_param method without the need of converting it to string. I want
DBI to parse it into the format,
On Fri, 10 Jan 2003, David Wheeler wrote:
> On Friday, January 10, 2003, at 01:17 AM, dLux wrote:
>
> > - To make it supported by the whole perl community, inclucing module
> > developers. For example, I want to pass a date object to the DBI
> > bind_param method without the need of convertin
On Friday, January 10, 2003, at 02:30 PM, Dave Rolsky wrote:
I think it'd be best if the driver module could rely on the object
having
a strftime() method. That'd be a minimal interface requirement that'd
satisfy basically all needs.
The problem with that is that then the particular $sth woul
On Fri, 10 Jan 2003, David Wheeler wrote:
> The problem with that is that then the particular $sth would have to
> have the necessary column bound explicitly:
>
>$sth->bind_param($param_num, $bind_value,
> { type => DATE_TIME });
>
> While that'd do-able, it's annoying. I'd
I'm going to make a dictatorial declaration for this project.
All code used in the project _must_ be licensed under the same terms as
Perl itself.
No arguing, no weird licenses, no "this software is free, I don't care
what you do with it".
K?
Good.
Now, a problem. The following modules need
On Fri, 10 Jan 2003, Dave Rolsky wrote:
> Now, a problem. The following modules need some license clarification:
>
> Date::ICal - no indication of license except for DLSIL of bdpOp. Rich,
> does that mean it does have the same license as Perl itself, or is that
> just a default setting?
Same li
So I'm starting to work on turning Date::ICal into DateTime.pm. The first
step was a global search and replace. That part went well, and I was very
proud of myself. I felt like a super-hacker ;)
Then I started added some of the simple-to-add Time::Piece methods, like
day_of_year, hms, ymd, and
On Fri, 10 Jan 2003, Dave Rolsky wrote:
> There's a couple of thoughts I wanted to bounce off of people before I go
> too much further. Please take a look at the Time::Piece API if you're not
> familiar with it.
Doh, and another thought, unrelated to Time::Piece.
What updating methods should th
[ must stop replying to self like the big freak that I am ... ]
On Sat, 11 Jan 2003, Dave Rolsky wrote:
> Right now, this module occasionally warns or carps about bad parameters,
> and then returns undef. I'm not a big fan of warnings in modules myself.
> I prefer to either simply return an indi
No, this has nothing to do with Mr. Dominus.
Rich, can you explain the pseudo-mjd system that Date::ICal uses for its
internals? And why didn't you you use real MJD?
Inquiring minds want to know. I think this is particularly important
since I was hoping to use this format as the basis for inter
28 matches
Mail list logo
