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.
