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 a
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
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 or
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
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
quote from=Dave Rolsky
- 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
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, which
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. 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
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 matter
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.
Just
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 realized that some
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
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 converting it to
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
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 rather
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
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 the
[ 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
24 matches
Mail list logo
