1) Why have different 'new' and 'from_epoch' constructors? Couldn't one
always use 'new' and have the module figure out what information to
initiatlize itself with by seeing if either the 'year' or 'epoch' name
parameter was passed? I think it would provide a cleaner and more
consistent interface.
I'll leave this one to Dave, but I'm guessing its because of the amount of code in the constructors. You'd have to wrap them into extra subs really. And then you'd have to test the parameters passed to new(). You'd have to make sure that if epoch() was included then no hour() minute() second() etc were included.
Not too hard, really, so maybe Dave has another reason.
2) However, if you continue to provide different constructors, then when
using from_epoch, why require the 'epoch' named paramter? Why not assume a
single argument is an epoch value?
All parameters are named in DateTime. It's a convention we use and while it can be annoying for single-parameter methods it saves confusio.
The from_epoch constructor can take up to three parameters:
$dt = DateTime->from_epoch(
epoch => time(),
time_zone => 'Australia/Melbourne',
locale => 'en_AU',
);If you start assuming a single argument is a particular parameter, which do you go with in other cases. If you change one method, you have to be consistent.
$dt = DateTime->new( 34 );
Is that 00:00:34 or 00:34:00 or 0034-00-00?
3) You could offer one or more of these:
# prints '2003-05-04 12:55:10'; print $dt->ymd_hms; print $dt->ymdhms; # prints '2003-05-04 12:55:10.123456789'; print $dt->ymdhmsn;
We offer strptime() in the core because of the plethora of options that could be offered:
$dt->ymd;
$dt->dmy;
$dt->mdy;
$dt->hm;
$dt->hms;
$dt->hmsn;
$dt->ymd_hm;
$dt->dmy_hm;
$dt->mdy_hm;
$dt->ymd_hms;
$dt->dmy_hms;
$dt->mdy_hms;
$dt->ymd_hmsn;
$dt->dmy_hmsn;
$dt->mdy_hmsn;
And that's just the numeric posibilities. Once you want day or month names you have to increase the list exponentially.
HOWEVER, that said, I'd like to see some sort of a default format method:
$dt->set_default_format($strftime_format);
print $dt->default_format;
print "Stringified with default: $dt";
4) Why not add the two most popular uses as convenience functions: my $dt = DateTime->yesterday(); my $dt = DateTime->tomorrow();
It comes back to the plethora of accessor (and constructor) methods again. Maybe these should be in DateTime::Format::Business.
$biz = new DateTime::Format::Business(
%monday_to_friday_nine_to_five
)
$dt2 = $biz->tomorrow( DateTime->now );
Then when you're open M-F and you ask for tomorrow() on a Friday, you get Monday.
If $biz is initialised without parameters it's like you're at 7-11: Every hour of every day is included. Then if you ask for tomorrow() you'll get the following day.
Also, is anyone working on Sybase support for DateTime::Format::DBI?
Not that I've heard of. If you'd like to give it a go we're all here to help. Grab one of the other DT:F:DBI modules and read the developer docs on the website.
Cheers! Rick Measham
Senior Developer PrintSupply - Print Procurement & Supply Management 18 Greenaway Street VIC 3105 Tel: (03) 9850 3255 Fx: (03) 9850 3277 http://www.printsupply.com.au/
