On Friday, January 10, 2003, at 09:52 PM, 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.
FWIW, that's what Date::ICal already had implemented, I believe.
Sounds good to me.
Might make sense to implement a decorator that adds these later -- if people really want them.Alternately, how about names like "day_of_week" and "day_of_week_1" or something like that, so its _really_ clear what each does?
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, see earlier question)
day_name - full name
day_name_abbr - abbreviated name
I think this makes more sense than the Time::Piece API. The "name" is the
full name, not the abbreviation. If you want the abbreviation, ask for
it.
Agreed. On Friday, January 10, 2003, at 10:24 PM, Dave Rolsky wrote:
I see several possibilities:I think that this is an excellent idea. It's a good tradeoff between flexibility and simplicity. People who just want setters will be able to fake it like this:
- _Nothing_ is an updater. There is no add() method on objects, only on
the class (for overloading). The only way to "update" a date object is to
replace it with a new object.
- Provide a single set() method, which takes the same parameters as new().
- _All_ component accessors are updateable. So day_of_week(),
day_of_year(), etc. can all be updated. A slight variation of this would
be to provide set_day_of_year(), set_month(), etc.
The first option has the advantage of greatly simplifying the internals.
Once you calculate the julian day and seconds for an object, it just never
changes. The disadvantage is that the API may seem odd to some folks.
But we could still provide something like this:
# same as $old_date but day of month is 5
my $new_date = $old_date->clone( day => 5 );
$date = $date->clone( day => 5 );
And I like the idea of static DateTime objects.
I favor exceptions myself, since I think if something is wrong, it shouldI like exception, too, and you know that I'm a fan of Exception::Class. However, it'd probably be ideal to allow users to determine how to deal with these things, a la DBI's approach.
be considered catastrophically wrong, but I know this is a serious bone of
contention. Aren't you glad I brought it up?
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
