<quote from="Dave Rolsky">
> - timezone-handling
Yes, I talked about this. It should use the Olsen database to get _real_
timezone. I don't think it can rely on POSIX stuff since it needs to work
across as many platforms as possible. Jesse Vincent began some code to us
the Olsen db from Perl. It's in the reefknot CVS as Date::ICal::Timezone.
> - configurability with localizable variables
If you're talking about the stuff in Class::Date like
$Class::Date::RANGE_CHECK, I _really_ dislike this interface. This sort
of stuff should be settable on a per-class and per-object basis, not by
exposing global variables.
But I'm sure some of the things that Class::Date handles via these
variables will need handling, like the above-mentioned range checking.
I disagree with this, because handling these things are not
object-dependent, but context-dependent. I need to write a function,
which handles dates in one way, but I don't want to force users of the
module work dates like this.
When I have a function, which prints to a web page, then I localize the
$Class::Date::DATE_FORMAT, and it is used in "print" statements. It is
not an object-attribute, because it belongs to the
execution-context.
> - exportable "datetime", "localdatetime", "gmdatetime" functions for
> short-cuts of the constructors.
I like the way Time::Piece overrides localtime and gmtime. I don't see a
need for a whole mess of exported functions, though, and I'm inclined to
export nothing by default.
I afraid of this thing, because it can mess up with other parts of the
code, but anyway in the newer versions it should be okay.
> - Object for an invalid date
Can you explain why this is useful?
When a date is invalid, then the program does not croak if it is
referenced, and we can pass error-information in it. I won't tell it is
a perfect solution, better way of handling invalid dates are welcome.
Szab�, Bal�zs (dLux)
--
god:~# create world
Segmentation fault (core dumped)
