On Tue, 18 Jul 2006, Zefram wrote:
I think it's a very important architectural issue. To my mind a date
(or date+time) exists quite independently of calendars. Each calendar is
merely a way of representing these dates. The DateTime way makes it look
like the expression of the date is part of its identity. Of course, if
one has the right mental model, that it is the RDN that directly encodes
the abstract date identity, then it becomes clear that what the DateTime
(or DateTime::Calendar::Whatever) represents is not really the date but
some calendar-specific aspects of date representation.
This is all interesting stuff, but really, you have to be a pretty big
calendar/datetime geek before you think about it.
For the vast majority of users, they want a class/object that represents
"the calendar". They may not even know that "the calendar" is really the
_Gregorian_ calendar. They don't care about the abstract concept of "a
point in time" or any of that. They have a date, and they need to add 30
days to it, or they need to know how long until their mom's birthday.
So even if I were to rewrite the DateTime.pm code to separate it into
"abstract point in time" and "Gregorian bits" I'd _still_ make
DateTime.pm represent the Gregorian calendar.
Something you left out of your description: the date data in a DateTime
can be modified. Here once again the object is not representing a
date per se. If I consider the date that in ISO 8601 is represented
as "2006-07-18", it is meaningless to say that I "change its month
to August". That date is irrevocably in the Gregorian month July.
Yet DateTime lets me do
$dt = DateTime->new(year => 2006, month => 7, day => 18);
$dt->set_month(8);
print "$dt\n";
=> 2006-08-18T00:00:00
Of course I haven't changed 2006-07-18; all I've changed is the content
of a modifiable part of the DateTime object. So a DateTime actually
represents a *variable*, typed to hold a date (and time), viewed from
a distinctly Gregorian viewpoint.
Again, this is really useful to a heck of a lot of people. You're arguing
correctness, but I think you're completely ignoring most users.
Anyway, having rambled a bit there, the point was that this is another of
the bits of baggage that comes with DateTime that I'd rather do without.
Which is why I started writing much plainer date-handling modules.
Modules which while interesting are unlikely to be comprehensible to most
folks. OTOH, for people who need TCB maybe your Time::TCB module is the
right tool for the job.
As an aside, I've gotta say I'm really disappointed that you went to the
trouble of writing all this code _before_ talking to anyone on this list.
You have a lot assumptions about my intent, and the intent of the project
as a whole, but AFAICT most of your assumptions are wrong, and I think you
could've found that earlier, to the benefit of all of us.
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
