On Tuesday, January 14, 2003, at 07:24 PM, Dave Rolsky wrote:
On Tue, 14 Jan 2003, Matthew Simon Cavalletto wrote:
Agreed, strftime per se is Gregorian-centric.
Ok, then what were you proposing moving out of (or not putting in)
DateTime.pm in favor of putting it in a library.
I (and
On Tuesday, January 14, 2003, at 06:58 PM, Dave Rolsky wrote:
I question whether or not strftime (as used for Gregorian calendars)
will be terribly useful for other calendars, since at least some
portion of the specifiers won't translate.
Agreed, strftime per se is Gregorian-centric.
(Other
On Tuesday, January 14, 2003, at 03:26 PM, Dave Rolsky wrote:
I'm concerned that this approach may end up requiring that
DateTime::Calendar::Discordian to be a subclass of DateTime, and I
know you've recently argued that calendars that aren't Gregorian
shouldn't be subclasses of DateTime due
On Tuesday, January 14, 2003, at 03:03 PM, Dave Rolsky wrote:
use DateTime::Parse::MySQL; # this needs a better name
I've suggested "DateTime::Format::MySQL".
Actually, I'm leaning towards DateTime::Representation::* at the
moment. Format is correct if read as a noun, but confusing if rea
On Tuesday, January 14, 2003, at 02:33 PM, Dave Rolsky wrote:
On Tue, 14 Jan 2003, Matthew Simon Cavalletto wrote:
Modules like Date::Discordian or Date::Maya, which have no internal
storage format and only exist to convert to and from other calendar
formats, could easily be refactored to
On Tuesday, January 14, 2003, at 02:16 PM, Dave Rolsky wrote:
My constraints are:
1. A module should be able to choose to implement parsing, formatting,
or both. [...]
Definitely.
2. I really want to avoid runtime module loading. [...]
Agreed, in a mod_perl context you'll definitely be abl
On Tuesday, January 14, 2003, at 12:55 PM, Dave Rolsky wrote:
use DateTime;
my $dt = DateTime->new( 'MySQL' => $mysql_dt );
print $dt->to_string( 'MySQL' );
use DateTime;
use DateTime::Parse::MySQL;
my $dt = DateTime->from_mysql_datetime( $mysql_dt );
print $dt->to_mysql_st
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 se
On Monday, January 13, 2003, at 02:51 PM, Dave Rolsky wrote:
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 Da
On Monday, January 13, 2003, at 03:09 AM, Dave Rolsky wrote:
Except as you point out, this could confuse people who don't think of
the calendar as the Gregorian calendar.
I agree, that's a drawback.
DateTime::Hebrew::Passover -- Was DateTime::Algorithm::Passover
Same here. Generally
On Sunday, January 12, 2003, at 05:30 PM, Dave Rolsky wrote:
[...] keeping in mind that calendar-specific modules will be
DateTime::Calendar::X, not DateTime::X [...]
I think the "make Gregorian explicit" line of reasoning actually
supports moving the various calendars up to second-level name
On Sunday, January 12, 2003, at 05:55 PM, Dave Rolsky wrote:
On Sun, 12 Jan 2003, David Wheeler wrote:
The advantage is that the interface is exactly the same regardless of
calendaring system, and we deal with the issues of allowing DateTime
to return different calendar types right now, up fr
On Sunday, January 12, 2003, at 05:27 PM, Dave Rolsky wrote:
On Sun, 12 Jan 2003, Matthew Simon Cavalletto wrote:
Ick. That's clearly not as nice as just saying $dt->hour(17).
Whether this method is an updater is an entirely different can of
worms ;)
If not, it'd presumab
On January 12, 2003, at 07:29 AM, Antonios Christofides wrote:
(b) It's faster to use
($year, $month, $day) = datetime_object -> strftime('%Y', '%m',
'%d');
than
$year = datetime_object->year;
$month = datetime_object->month;
$day = datetime_object->day;
because i
On January 12, 2003, at 07:29 AM, Antonios Christofides wrote:
Get rid of the methods/functions returning year, month, day of week,
day of month, day of year, hour, minute, second, week of year, week of
month, whatever, and use an enhanced strftime [...]
This enhanced strftime is a very nice i
On Sunday, January 12, 2003, at 10:48 AM, Rich Bowen wrote:
On Sun, 12 Jan 2003, John Peacock wrote:
We really have to go with ISO because that battle has already been
fought and won(?) in the international community.
Well, I was going to say the following:
This is not about either ISO stand
On Friday, January 10, 2003, at 09:52 PM, Dave Rolsky wrote:
I propose the following:
month - 1-12
month_name - full name
month_name_abbr - abbreviated name
day - _day of month_ (makes sense in context of year() and
month() methods)
day_of_week - 0-6 (or 1-7, se
On Saturday, January 11, 2003, at 03:49 PM, Dave Rolsky wrote:
On Sat, 11 Jan 2003, Rich Bowen wrote:
On Fri, 10 Jan 2003, Dave Rolsky wrote:
Can we simply declare 0-based as the standard for day of week and
day of year, and 1-based for day of month, month of year, and week
of year.
Things
t, so that we
can use the iteration and bounds-checking methods that provides.
So, who's ready to chew ass and kick some bubble-gum?!
I'm definitely interested in contributing to this effort.
-Simon
--
Matthew Simon Cavalletto[EMAIL PROTECTED]
Evolution Softworks www.evol
On Friday, April 12, 2002, at 07:40 PM, Frodo Baggins wrote:
> As far as I can understand, the problem is in the routines
> converting to end from day-month-year dates to JD.
>
> These routines are interesting in theyr own respect, so I written a
> module to handle them. If someone is interested
20 matches
Mail list logo
