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
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
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
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
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, 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 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
16 matches
Mail list logo
