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.

Alternately, how about names like "day_of_week" and "day_of_week_1" or
something like that, so its _really_ clear what each does?
1. Declare one standard, but don't make March 1 be day-of-month 0, and I'd prefer that March wasn't month 02. That just guarantees the extra bytes in everyone's code, somewhere between calculation and output...
2003-00-10 what day is that? Today?? No, today should be (2003, 01, 11) at all times.
2002-12 is January 2003 ?!!! No, 2002-13 would be January 2003.

Even though I'm totally accustomed to 0-based indexing of months a la localtime, it always reminds me of someone's email signature that says: "There are 10 kinds of people in the world: those who get binary and those who don't."

A good API shouldn't employ the equivalent of an inside joke.

Having a way to coerce the non-standard would also be good; but I'd caution that someone might mistake 'day_of_week_1' as having something to do with 'week 1', i.e., 'the first week'.

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.
2. Yes. All good. How about also using this convention for a consistent way to indicate numerical vs. string?

As in:
Anything with _name - string
Anything with _of - numerical
Anything plain - numerical (does this work? day, month, year, ...)

At times for clarity I also use:
Anything with _num - numerical
Anything with _str - string

I need _num at times when _name doesn't quite make sense for its converse:
day_ord - e.g., 'Fifth' [the proper ('full') ordinal]
day_ord_num - e.g., '5th' [really an abbreviation]
because day_ord_name or day_name_ord might imply something like 'Wednesdayth'.

OTOH, this would be efficient:
day_ord - '5th'
day_ord_str - 'Fifth'

Not saying here that DateTime.pm should provide ordinals, but just that it would be great to extend its method-naming scheme downstream, and an unambiguous distinction between string and numerical returns would help...

3. I vote for static DateTime objects. I think that makes it easier to keep track of complicated namespaces, re-entries, etc., anyway.

4. For setters, I'm happy with usages like
$new_date = $date->clone( day => 5 );
and its implied
$date = $date->clone( day => 5 );

Thanks, Dave.


- Bruce

__bruce__van_allen__santa_cruz__ca__



Reply via email to