Thanks for the feedback, Tim.
Since work priorities have shifted for me, I'm not going to need this module as soon
as I thought I would. Right now, I don't know when I'm going to get to it. In short,
if anyone else really wants this module and is willing to write it, don't wait around
for me to do it. ;^) If not, I'll get to it eventually.
Dave
On Fri, May 16, 2003 at 10:03:46AM +0100, Tim Bunce wrote:
On Thu, May 15, 2003 at 11:17:42AM -0500, David Naughton wrote:
On Wed, May 14, 2003 at 11:22:10PM +0100, Tim Bunce wrote:
On Wed, May 14, 2003 at 12:54:52PM -0500, David Naughton wrote:
Anyone working on DateTime::Format::Oracle? I'd like to have it, so if not,
I'm willing to do it.
What would it do, exactly?
I'm not *exactly* sure. All I know right now is that I would like to do:
my $dt = DateTime::Format::Oracle-parse_datetime( $oracle_formatted_output_date
);
my $oracle_formatted_input_date = DateTime::Format::Oracle-format_datetime( $dt
);
I recall Oracle supports about 7 non-Gregorian calendars.
How you it integrate with Oracle NLS settings?
Are you implying that I may be under-estimating the complexity
of dates and times in Oracle? If so, you're probably right.
I'm fairly new to Oracle. Are you also implying that DT::F::O is
unnecessary or useless? Can I get the same functionality with
already existing modules? Both? If so, please explain.
I suspect you're only thinking in terms of the most common DD-MON-YY[YY]
format and other obvious and unambiguous variations on it.
If you think DT::F::O would be useful, you raise some good questions
about the calendars and NLS settings. Since Oracle offers so many
date formatting options, DT::F::O would probably have to be more
complex than DT::F::(MySQL|Pg). Maybe DT::F::O would have some way
of understanding Oracle date format strings? That way, maybe one
could feed the same format string to Oracle and DT::F::O and convert
happily ever after?
Yes. Adding an optional oracle 'format model' parameter to
format_datetime would be a good start. As would adding a static
method to set the default for a class. The next step would
be allowing object instances of DateTime::Format::Oracle which
can hold their own settings:
my $dt_f_oracle = DateTime::Format::Oracle-new(format = '...');
$str = $dt_f_oracle-format_datetime( $dt );
So multiple settings could be used easily in an application.
The oracle 'format model' parameter would typically be hardcoded
by 'lazy' applications that 'know' what setting is used locally.
But generic code would need to fetch the appropriate NLS value
from the oracle server being used.
I suspect fully generic date parsing for input may be harder,
but the basic princple of using the format model still applies.
The primary goal would be to parse just the cannonical format
that corresponds to the given format model.
In any case, I appreciate your feedback, Tim. I asked for feedback
before plunging ahead and writing the module hoping to get input
from people like you. Any advice would be much appreciated!
Don't be fooled into thinking I really know what I'm talking about :)
Tim.
