On Sun, 12 Jan 2003, Dave Rolsky wrote:
> On Sun, 12 Jan 2003, David Wheeler wrote:
>
> > My apologies for misunderstanding. What I meant was that, yes, the
> > 1-starting month numbers are values, rather than array indices.
> > However, nowhere that I know if is there a situation in which month
> > numbers are returned 0-indexed, that is, as array indices.
>
> You're wrong, you do know exactly such a situation. Perl's localtime
> (which is based on C's localtime) returns exactly this (0-11). Days of
> week are 0-6 (Sun-Sat), and day of year is 0-364.
All of which are values that you would use in a further calculation of
some kind, rather than on an interface. Unlike date of month, which is
consumed by humans directly, and as noted _is_ "1-indexed."
> But this interface seems rather outdated and borderline pathological,
> since it also returns year as number of years since 1900. So it hardly is
> the basis of a good _generally useful_ datetime API!
Spurious logic. No one's claiming it's that. But if it has good features
or design elements they should be considered on their own merit.
> > But overall, my point is that, with true DateTime objects with good
> > localization support, there will be very little need for array indexes
> > for months, day of week, or even day of month.
Here's where I think you're wrong. I think it's fantasy to imagine that
the new DateTime interface will be so comprehensive and so perfect and so
widely accpeted and implemented that the only way anyone will ever use a
DateTime object is to produce data that will be output to the user as is.
Reality is that while a good interface will go a long way towards that
goal, there will be a lot of users of the objects that will expect
zero-indexed values for a lot of fields for a variety of reasons. And if
you want the module to be really useful you need it to be plug and
play. That's why I've argued for the 1-indexed data to _not_ be the
default; the only users of that are going to actual humans and UIs and
they are thus well able to turn a switch on. Machines are more dense and
will expect what they've always been fed. I just think it's naive to
believe that "there will be very little need for array indexes" in the
real world.
> > So it makes sense to
> > make the 1-based enumerations the default for these things, and provide
> > *_0 methods for those who still want array index-type numbers.
>
> Yep.
>
> Let's end this particular discussion (0-based vs. 1-based). I'm happy
> with the 1-based API as default, with *_0 methods for when that is needed.
Let the record show that not everyone is :)
- nick
~~~~~~~~~~~~~~~~~~~~
Nick Tonkin {|8^)>
