Sorry for the delay. Just caught this off of use Perl;
One thing to keep in mind: the only thing I (and most people whose code
I maintain) want out of date parsing 9 times out of 10 is:
$date = $fh;
$something = Some::Thing-new($date);
$tomorrow = $something-tomorrow;
On Monday, January 13, 2003, at 10:14 PM, Dave Rolsky wrote:
I _don't_ want to discuss implementation of this. I want to talk
about the API!
Agreed; I'm making this argument specifically because I think the
proposed API is clearer.
Looking at the two alternatives, does the second really
Dave Rolsky wrote:
use DateTime;
use DateTime::Parse::MySQL;
my $dt = DateTime::Parse::MySQL-new_datetime( $mysql_dt );
print DateTime::Parse::MySQL-mysql_datetime( $dt );
I can also imagine some other scheme, where parse/format modules register
the formats they can handle with
On Mon, 13 Jan 2003, Jean Forget wrote:
Well, it is not *that* simple. In addition to creating a new
calendar, Fabre d'Eglantine and Romme changed the duration of
the hour, minute and second, so each day would be split into
10 hours, each hour into 100 minutes and each minute into 100
On Mon, 13 Jan 2003, Rich Bowen wrote:
It's an interesting point in this case, with this being one of the very
few calendars that changes how time is handled. However, since the
purpose of the module in question is conversion between Gregorian and
French Revolutionary, I would expect that it
On Mon, 13 Jan 2003, Matthew Simon Cavalletto wrote:
What's the benefit of making this distinction between core and other
formats?
Because core parsing would be available simply by doing:
use DateTime;
That's about it.
Why not define a parser interface and include the basic formats as
Continuing the discussion with Rich Bowen (Mon, 13 Jan 2003 06:28:14 -0500 (EST))
On Mon, 13 Jan 2003, Jean Forget wrote:
Well, it is not *that* simple. In addition to creating a new
calendar, Fabre d'Eglantine and Romme changed the duration of
the hour, minute and second, so each day would
On Sun, 12 Jan 2003, Yitzchak Scott-Thoennes wrote:
Another goal I see as worthwhile would be a non-partisan document
comparing the strengths and weaknesses of the existing modules, with a
link to it from the date and time categories on CPAN.
This has been one of my goals for many moons. In
I'm glad this is starting up again. We here in VMS land have very
nice date and time functionality built into the OS; I want to keep
an eye on the direction this takes just to make sure it doesn't
become drastically incompatible with VMS timestamps.
Just one comment for now:
Dave Rolsky
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
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
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, 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,
I've been using Perl for several years and have always HATED doing
anything with date/time information. I've avoided it whenever possible
because finding a module that will do function(x), actually works and
has up to date documentation is nearly impossible.
I'd kick in a few hours here and
On Thu, 9 Jan 2003, Darren Young wrote:
I've been using Perl for several years and have always HATED doing
anything with date/time information. I've avoided it whenever possible
because finding a module that will do function(x), actually works and
has up to date documentation is nearly
20 matches
Mail list logo
