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
On Mon, 13 Jan 2003, Martijn van Beers wrote:
But nothing fancy, just a few formats should be supported in the
base class, including epoch time, ICal, and maybe ISO 8601.
I wouldn't call epoch arguments parsing, but I would really like it if
this wasn't in the base class. Making people go
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 Mon, 13 Jan 2003, Martijn van Beers wrote:
On Mon, Jan 13, 2003 at 01:58:59PM -0600, Dave Rolsky wrote:
I agree that epoch is bad, because it's so limited, but it's a standard
that a lot of people are familiar with, so it needs to be supported in the
core object.
That is exactly why
I need to find more time to read through the flood of messages...but
wanted to mention right away that things look to be going astray.
Apologies if it is not so.
What's the goal here? If it is creating a base class for date/time
modules to standardize on, that won't work. I don't think the
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
quote from=David Wheeler
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
On Saturday, January 11, 2003, at 11:08 AM, dLux wrote:
I imagined the following stringification method:
use overload ''= as_string;
sub as_string {
my ($self) = @_;
my ($package) = caller;
no strict refs;
return $package-FORMAT_DATETIME($self)
if
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
On Thu, 9 Jan 2003, Chris Josephes wrote:
2. Use the DateTime:: namespace. The [EMAIL PROTECTED] cabal doesn't
like it? That's nice. Their buy-in is nice, but lack thereof does
not prevent success. And in my experience, when presented with
working code that's being used by a bunch of
On Thursday, January 9, 2003, at 04:35 PM, Dave Rolsky wrote:
On Thu, 9 Jan 2003, Chris Josephes wrote:
Why not just a DateTime object, like we already have a CGI object?
I suppose that's possible too. I think the one thing the
[EMAIL PROTECTED]
cabal dislikes more than a new top-level
and there if you need some extra coding
hands.
-Original Message-
From: Dave Rolsky [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 09, 2003 4:04 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; Matt Sergeant; [EMAIL PROTECTED]
Subject: Picking up the ball
[ CC'd to the Mpls Perl
[ 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. ]
Ok, the state of Perl's date and time modules continues to suck. They all
have
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
38 matches
Mail list logo
